This is a simplified answer to the prompt in the title. I know as much as anyone that blockchains get complex. But per my last post we need to keep things simple. As an industry we’ve done a bad job at that. I’m part to blame. Here’s me taking a step back and ELI5ing an answer:

1. Sufficiently decentralized, and not one bit more: One of my favorite thought pieces is Haseeb’s post on sufficient decentralization. We have been over designing blockchains. Good news is this problem is solved. The challenge is that it is hard to quantify decentralization. However, if you’re sufficiently versed in the space, it’s not hard to have a good sense. Some examples
   • Ethereum L1: over decentralized
   • Ethereum L2 that posts fault proofs today: sufficiently decentralized (thereby justifying Ethereum L1’s over decentralization
   • Solana: sufficiently decentralized
   • Mina: over decentralized
   • Cosmos SDK chains: sufficiently decentralized
   • Cardano: over decentralized
2. High throughput: historically referred to as TPS, a better consensus has formed around gas/second (at least for EVM chains). While it’s clear why higher is better, anything below a capacity of 10 MGas/s today is probably not a healthy contender to be a good blockchain (except for Bitcoin and Ethereum).
3. Fast confirmations: we’ve come a long way with this one. Bitcoin started with ~50 minutes. Thanks to the bar set by Solana, we’re now looking at sub second confirmations across modern chains. That is a reasonable settlement time for most modern applications.
4. Battle tested development environment: while many runtime environments (e.g. EVM) support multiple different development languages and environments today, the popularity of a development environment in terms of number of worldwide developers is not sufficient. Applications that touch money and other forms of internet value have different considerations and failure modes that don’t benefit from battle testing in a web 2 context. That’s why Solidity reigns supreme. Rust is becoming a contender but only by virtue of going through the grinder thanks to Solana.
5. Brand and narrative that is orthogonal to existing ones: Blockchains are such general purpose tools that when one catches escape velocity, it creates its own gravity and sucks in everything else that’s narratively close enough to it. You need to be far enough to not get caught. Solana did this well by countering Ethereum’s “we’re going to design smart and complex systems to ensure everyone can participate” with “yolo, we’re going to throw as much compute as possible to the problem”. I’m oversimplifying, but that simple distance helped them create their own independent gravity pool.

Conversely what are some design considerations that smart people think matter, but they don’t?

• Privacy: this is a tragic one as it should matter, however regulatory pressures sucked the oxygen out for it to organically mature. We are getting privacy tools built on existing L1s, but if the regulatory environment was more permissive, chains like ZCash could have thrived.
• ZK/FHE/TEE/drop-in-fancy-cryptography compatibility: All modern blockchains are Turing complete machines, meaning they can run any code. How efficiently they run certain pieces of code can change. Banking on the explosive potential of sophisticated forms of cryptography such as ZK, some chains optimized themselves for those pieces of computation. However optimizing yourself for something that is yet to prove PMF slows you down in everything else that has PMF. Instead, other chains can wait for the right moment and pick the right optimizations when they know what the PMF looks like. This is why Ethereum and Solana have gained more ZK application adoption than purpose built ZK chains like Mina or Aleo.
• Fancy tokenomics: This can certainly help as a way to bootstrap community, but over the long term you need demand from application users to provide the oxygen for whatever fancy tokenomics you might have. And that demand is predicated on everything else I shared in the first section.

Simple, right? If only. We'll see how the above stands the test of time.