We all knew the junior engineer that wrote some strange code or commented on your PR saying "there's a faster way to do this!". I remember doing it myself in my PHP days. Switching to switch statements and reverse while loops are what I remember the most. But in most cases these days I'd get on someone for pre-optimizing their code. There are better things to focus on and it actually be to our detriment if the code is more difficult to maintain.
Without further ado, here they are ordered from most important to least.
Maintainability - if it takes too long to fix a critical bug or causes slow downs for other engineers then it's likely a compounding time sink. We can't just think of ourselves when coding, but all of the future maintainers. I've given the analogy of comparing software to machines dozens of times. The more parts and they more complex either are the more likely they are to break. Keep it simple, stupid.
Discoverability - Naming patterns of files and their exports, and where they are stored are important. It's ideal to be able to identify, discover, and find files and their exports as quickly as possibly. I personally prefer a module type system, where each vertical gets it's own folder, so everything you need is in one place. Naming a file index.ts is equally harmful -- what happens when someone has 3 of those open, how will they know what is what? Be nice to brains.
Scalability - At some point it's worth thinking about scalability, but it shouldn't be a top concern for a new project. Use JWTs for stateless auth and it will bring you far. When teams get too invested too early we end up juggling a couple of dozen microservices and waiting around for builds and releases, both waste even more time and increase the complexity; therefore, increase cognitive overhead.
Defect free code - You hate bugs, I hate bugs, we all hate bugs, but they are going to happen. We can put in tooling and monitoring to try and catch them early and often, but they always seem to find their way back in. This is why it's a great idea to look at the patterns of bugs and have retrospectives. It could be a weird quirk with a library you recently integrated, or it could be something that's solved easily like making cache read only, so people don't accidentally poison it.
Performance - And the least important can be found here. Typically it's a better investment to make an application scalable than performant. A way to think about it is performance is scaling up and and what I referenced as scaling outward. Outward gets you more. It's not to say the app should be an old slow dog, but be reasonable. And try not sacrifice maintainability for performance.