I mostly agree with you, but I feel like there is benefit in the knowledge of how inputs/processes do affect performance (aka Big O) as that demonstrates just a

I mostly agree with you, but I feel like there is benefit in the knowledge of how inputs/processes do affect performance (aka Big O) as that demonstrates just a deeper level of thinking. It's pretty easy to get someone to understand doing stuff more than you have to is bad aka (no data calls in loops, sort at the DB not on the server, etc), but it's another type of developer to say "hey, this works good for now, but if this client has over X# of widgets we're going to run into performance problems, why don't we see if we can build a caching layer to share data across widgets". Just that type of person in a room bringing up those issues saves close to 100 man hours by the time that bug gets found by a client, escalated through client support, pointed, moved into a sprint, retested, etc. That's saving the company a lot of money in a very concrete way and delivering a better product.