Yeah, that's exactly right. I was reading the article with that lens, and found some of its examples less than compelling. It may not matter if Linq is doing a bunch of allocations; you could always replace it with the in-place loop later. Starting with Linq doesn't cost any potential energy.

I had a couple more nuanced reactions to the OP.

a) While this is an argument that needs to be made more often, and one that I've made before, characterizing careless optimization as just lack of thoughtfulness is underestimating the problem. The real problem when I end up writing carelessly slow code is that I had no conception of the internal details of some library or service. The best programmers know they have to gradually break down every abstraction in their mind, and gain the ability to think about its internals when the need arises. It took me a long time to realize that my mindset when using a library should be to gradually understand how it works. Heck, I stared at the sql statements emitted in Rails logs for years before I realized they were telling me something useful. It's not about not being thoughtful, it's about being on a path of learning long before you need it. And we need to be spreading this word far and wide.

b) The standard of "all great software programmers I know are proactive in writing clear, clean, and smart code. They pour love into the code they write." is incredibly rare. That isn't going to change. So as long as we place the onus on considering alternatives up front, we're always going to be disappointed. Particularly when new programmers come in late in a project's life cycle and weren't around since it started, they may not actually be aware of all the different situations it's invoked in, and how bad worst-case might be. They'll also be less intrinsically motivated because they have less of a sense of ownership for the codebase. Things get even worse in projects that started out as prototypes, because of course there it makes sense to just go with the first idea that pops into your head.

I think we should make it easy for people to contribute by making it easier to perform radical rewrites of parts of codebases. That way there's less pressure on perfectly checking all possible alternatives up front.

The difficulty of a rewrite has less to do with the raw effort of the rewrite and more with the prospect of causing regressions, and the stress emanating from that prospect. I've been exploring making codebases more rewrite-friendly, using more comprehensive white-box tests: https://news.ycombinator.com/item?id=11052322.