Over its history, Bitcoin users per nodes has declined from >1:1 to now something like <1:700 (from the calcs upthread).
Looking at it another way... # of nodes contributes an element of security (resilience) where N is the minimum to run, N+1 is with one 'hot failover' system for backup, we have something like N+7000... which so far has been more than enough.
....
As (A) increases, Bitcoin's value increases. As (B) increases, Bitcoin's cost increases.
Thus if <1:~700 has been sufficient with a market cap of 3-4 billion one could extrapolate a minimum of full nodes desired with a more valuable economy as there is a loose correlation between the incentive to attack a more valuable network and the costs inherent to do so. So if Bitcoin grows to a market cap of 8 billion we would want around <1:~350 full nodes. 16 billion we would want <1:~175 nodes. This shouldn't be a linear ratio continuously as supporting that level of security for growth isn't realistic even if we keep the block limit at 1MB. Perhaps if we start considering pruned nodes as having a certain amount of value in the total node count it can be extended much further.
I still believe what is more important is the type, quality, whom controls, and distribution of the nodes vs just the total node count but am fine if bitcoin is over-engineered where it focuses on both considerations. Additionally, I believe we should consider the value of 1GB pruned full nodes in context to the discussion with subsidizing security.
Thus we could either incorporate an incentive structure through price discovery methods to incentivize nodes and/or optimize core and add pruning, or we can have some external methods as discussed to accomplished these shared goals.
What we cannot do is simply sit idly by and assume nothing needs to be done either. To be fair many people who oppose this fork are actually working on projects like the 10k extra pogo nodes to address this issue. I think that if we have a comprehensive plan of action before the hardfork we can satisfy all our values and objectives.
There are more important things that can be done like setting up libbitcoin Obelisk nodes/servers to support other implementations than simply focusing on total node count for bitcoin core, but if the requirements are realistically achievable like you outlined with scaling up the total node count with market cap than there is no reason we cannot accomplish both at the same time.
So moving forward, if a plan is in place, with an incentive structure built that will sustain decentralization realistically, and we are achieving said goals before the hard fork, than is anyone opposed to increasing the blocksize limit and has specific objections in doing so?