A linear solution to a hyperbolic problem doesn't get you very far. Must be more clever.
Discussion
Blocksize can increase gradually over time allowing more people to on-board over time and keep fees at an acceptable rate.
You're missing the point that block size is a linear solution that can't be the entire answer to the problem without heavy centralization risk. Even with ZKP roll ups that would allow a full node to synchronize in seconds, the heavier the chain, the more intensive the computation is for the proover(s).
That aside...
What's an 'acceptable rate' ? Fees are a free market and block space is necessarily scarse.
Newer cpus processing power increases over time, older cpus get cheaper over time, hard drives get bigger and cheaper over time, this means nodes can get better over time. Centralization risk is people not being able to afford onchain BTC and having to use custodians or shared custody of their funds. The risk is having a chain that only the wealthy can afford in a self custody way, because we want to be able to run Core in a raspi from 2018 over tor. And then while trying to find another way to solve an impossible problem we add complexity to the chain. People that can't own/use btc won't run nodes, people can also share a trusted node if they want while keeping their keys. We already had a big blocksize increase with segwit and there was no problems with the number of nodes. About fair fees, we could either increase blocksize in a dynamic way watching the median block fees for X blocks to assess if a blocksize cap increase would be done, like the hashrate adjustment, or it would be done always, like 1% every year, or it had to be hardcoded and in the future we would have to deal again.
Perhaps there's a balance somewhere, but this isn't the full solution. I'm sure we will find more creative ways to stuff more transactions in the same block space, and we're already creating better trust minimized models of ecash on top of Bitcoin. Block size should be a last resort.