Qualitative “better” is frequently what design and front end people are concerned with.
If the solution to date range pickers is two individual pickers tied together with validation logic, most people will call that qualitatively worse from a ux perspective and probably code wise too. If I have to run a bunch of code to get the native element to do standard things, then why not just use a better propietary thing anyway. A date picker taking an extra 1.3ms to render on click is fine if it gets me a bunch of functionality that is not possible with the native version.
In other words, you seem to be defining “better” way too narrowly. Raw performance is one metric amongst many.
Another important quality about performance engineering is that it exposes, from deeper investigations, other unrelated technical problems that were otherwise not evident.
Perhaps the most important benefit of performance engineering is that faster software is capable of supporting features and experiments that slower software cannot.
So, its not that performance analysis is necessarily better than something else. Its important for its own sake to improve software quality generally. Of course, the very first step in any of this is measuring things with numbers and comparing those numbers. It is astonishing how many people in software cannot do this and become hostile to defend themselves against it.