The Most Optimally Performant Code is (Usually) Code Simple Enough for Most Humans to Understand; Not the Other Way Around
Anyone can write software. Even a machine can do it. Writing performant software is the hard part.
There's rarely a fixed pattern you can follow to get all the performance you want. Even slight changes to the design spec requires you to completely change the architecture in non-obvious ways to get the performance you want.
It's hard to predict what's going to work well and what won't until you try it. This is why when it comes to making performance improvements, you should implement the feature the naïve way first, then figure out how to get it to perform well later. This way, you can compare and validate the results in case your performance improvements actually ended up being slower than the naïve implementation.
In spite of that, there's a irresistible urge in all of us to "get it right the first time". It's only human nature. Why waste time doing the same thing multiple times when you can just do it right the first time? We spend lots of time preparing and making sure we won't end up making mistakes, not realising that in the time we took to prepare, we could've made multiple different implementations and found the most performant version much earlier (and the implementation we choose after preparing wasn't the most performant version anyway!)
When it comes to choosing the most performant implementation the first time, the general rule is: trust the human brain.
Humans are very lazy. That's great! They don't want to spend a lot of energy thinking and have a preference for simple solutions. This lets human beings operate on very low energy.
If you think about it, isn't that what performance optimisations are? You are implementing a solution that can get the answer using less compute cycles, or more simply, less "thinking effort". In a way, optimisation is just figuring out how to get the answer in the laziest way possible.
If you try to explain the system to a human and you realise that your system is too complex to explain, it's probably too complex to perform well too.
When writing code for a feature, think of it as a mechanic in a board game. If you have to explain to a human the rules of this "mechanic" in the game, what is the simplest way you can write these rules for them? If you manage to figure that out, you'll most likely end up with the most performant implementation just from that.
When you put it this way, it sounds obvious. Of course the simplest solution is the one that'll perform the best! You're cutting away all the unnecessary complexity and you're getting the answer in the most straightforward way. Yet, we still instinctually believe that the more complicated solution will be the most performant version.
We look at an algorithm that's a couple lines long. We can read through it and understand pretty quickly what it does and how it works. Then we look at a monstrosity of a code snippet that does the same thing but over a hundred lines long and assume that it's actually the "smarter" solution. Funny how our assumptions work.
With that said, this isn't necessarily a foolproof shorthand. The human brain and the computer don't operate the same way. There are a lot of things that are intuitive to the human brain but aren't to computers. Simple solutions can end up turning into monsters when writing it in code. Likewise, things that computers are designed to do very easily can be quite esoteric for humans.
Still, computer and human processing is similar than we give it credit for. You can get a very performant solution that both humans and computers can understand most of the time.
It's also important to mention that easy to understand code is different from easy to read code. Code understanding and code literacy are two different skills. It's easy to mistake simpler code for code that has less lines, though there usually is a correlation (but not causation!). This is important to keep in mind when talking about simpler code.