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.
I just recreated a multi-million pound company's functionality without a single algo or any thought of big-o.
Can you explain what deep algos or big-o knowledge I need to recreate booking.com. uber, airbnb, etsy, flickr, imgur, etc., but without their scale? Or maybe making an internal data input app with a basic rules engine, which virtually every business needs these days? No big o, as if you're only handling 10 million or so hits a year, you can make some pretty big mistakes and still have a nicely performing site. For algos maybe you might need one algo depending on the business, a ranking algo, or perhaps a pathfinding algo, something that will be extensively discussed on SO and laid out entirely for you, or you might just plug a library in. No CS knowledge required.