Optimising for simplicity first is almost always the right thing to do. Even if it turns out to be too slow you then have a reference implementation to confirm correctness against.
In my experience it's rare to correctly identify the bottleneck in code while writing it.
Some view simplicity more as minimizing lines of code, e.g., less moving parts.
I view simplicity more as increasing lines of code, the goal being to make the code very verbose. Sometimes this means more moving parts, but smaller "movement" at each step.
> In my experience it's rare to correctly identify the bottleneck in code while writing it.
Why? It is so easy, just think of the work being done and pick the big parts, those are the bottlenecks.
Only reason I can see anyone fail at that is that they don't know how long things take in their programming language, but that takes very little time to learn, and once learned you will know the bottlenecks before writing.
In so many cases the bottleneck is using bad data structures everywhere, that often gets you 100x runtime and doesn't show up in a profiler because it is spread out all over the codebase, that is the real bottleneck that never gets fixed and is why programs are slow today. To fix that you have to learn to know the bottlenecks as you write the program and not rely on a profiler. Profilers helps you find how long things take, they are really bad at helping you understand how to make the program fast.
The steps in this witty quote helps puts things in perspective as what anyone should do first when in doubt: "Make it work, make it correct, make it fast".
But sometimes you already have something that works, is correct and fast, but you still want to simplify: for example, when understanding _why_ that code is correct is too annoyingly complicated to explain and understand.
With AMD having 128 core CPUs with a 192 core coming soon... Depending on what you're doing, and how you're doing, there's a LOT of raw horsepower you can throw at a problem. For example, a classic RDBMS (PostgreSQL, MS-SQL, etc) over more complex No/New SQL solutions.
It’s factually correct due to hardware and compilers (néé transpilers) offering so much headroom, but part of me cries when you compare modern hardware utilization compared to how optimized-to-the-gills late generation PS2 games were.
I would argue that the fast part isn't optional for web apps (where "transpiling"), but it can be in many other instances.
I write a lot of data-pipeline code in Python that mostly runs once a day. Does it matter if it takes an hour to run instead of five minutes? Not really, as long as it's ready to go for the next run.
In my experience it's rare to correctly identify the bottleneck in code while writing it.