The current proposal 13 on Juno seeking to adjust the blocks per year param for it to more closely fit the projected issuance rate will very slightly alter the time per block. This brings me back to some thoughts about the realtime performances of Tendermint chains. Let's take a few examples:

Osmosis

Osmosis is a good case study because the chain usually doesn't require a fee to accept transactions, and every day at epoch (staking and LP rewards attribution) lots of transactions get into the blockchain in a very short period, which is a good indicator of how much a "real life" chain can handle at traffic spikes. There's how it breaks down:

average blocktime: 6.5 seconds per block
average transactions per block: ~50
spike transactions per block: over 300

All in all it handles it pretty well, from what I know it sits in a good equilibrium for it's use case. The same goes for Cosmos, with roughly 7 seconds per block, accommodating a steady 5-20 transactions per block. It could revamp the minimum gas fee structure to zero and still handle fine currently.

Binance chain

The Binance chain has some odd parameters in the field:

average blocktime: 0.5 seconds
average transactions per block: ~12
spike transactions per block: I rarely saw more than 30 transactions in a block

Choosing such a low block time might give a marginally "faster" feeling to transaction execution to the users (often funds movements), but the downside is that leaves very little margin for node sync for rounds. It's not unheard of for an internet link between datacenters of Netherlands and Australia to rarely reach a sub-second TCP response time, let alone a blockchain consensus round. There's little room for improvement possible there, which leads to the side effect to concentrating many validators in limited geographic locations (namely the IX hotspots New York, London, and Amsterdam). This for a very marginal user experience benefit (the block time could be 2 seconds with barely noticeable difference to the user, and each block would be more than enough to comfortably handle the same amount of transactions).

e-Money

The case of e-Money is interesting because that chain adapts block time "dynamically" to it's activity.

average blocktime: ~20 seconds
minimum blocktime: ~1 second
maximum blocktime: ~1 minute
average chain activity: about 1 transaction per minute

This chain has a payment use case, with it's NGM staking token and various fiat-backed stablecoins, so it needs to finalize transactions fast when they happen, while not wasting resources when nothing's happening. If you compare to a VISA/MasterCard payment, with the terminal recording the transaction, "calling home" to initiate a debit, it's not unusual for a transaction to require 2-3 seconds to complete. That's the amount of time a customer might expect to wait at the cashier. And accounting for mobile network delays, e-Money achieves transaction finality in about the same time.
VISA claims to handle about 1700 transactions per second, and from the peak performance per block of Osmosis above it really looks like a single chain like e-Money can handle almost as much.
And let's not forget e-Money chain is IBC-connected, if each country or region had a dedicated "e-Money zone" with local validators a user could automatically IBC-transfer their tokens to during travel for then use as main payment chain locally, this potentially scales up hundredfold (to say nothing of future performance improvements of transactions-per-block handling by validators).