In other words, the business should have ultimate authority and responsibility to structure incentives and pursue priorities. Up until the engineer crosses over a boundary and becomes part of leadership.
Tons of software would run faster if it DIDN'T use custom stuff. Don't load a JavaScript framework for form validation if using `required` and `pattern` are enough. Don't write your own sorting algorithm unless it's faster than qsort(). Don't write your own data storage engine if SQLite covers your use case.
Story time: I once wrote a memset() replacement because one compiler kept optimizing out my memset() call and didn't have memset_s(). It slowed my program down a lot. When I looked carefully I saw I was always resetting the whole buffer, even though I was keeping track of how much had been written to it. Fixing that lead to a ~10x speedup (0.1s to process a large word processor document went to 0.01s, occasionally 0.02s).
Most software is made by stitching together off-the-shelf components. I don't think people on the web need a warning about not writing too much custom code. The HN complaint about the web is regarding bloat from people who walk the mainstream road of web development. Loading a bloated framework to do whatever is an example of such mainstream development.
In many cases, taking performance into account up front adds little overhead and won’t appreciably affect the design. But, if you codify some algorithmically inefficient approach into your public API, you’re going to find that hard to unwind. The engineering team should advocate for that when designing the product.
A common complaint on HN is bloated web performance. Surely we don't think the web is bloated because of too much custom code as opposed to too many off-the-shelf components?