I also think there are no serious problems with the blockchain size
That's good. And I would have loved to see you start with that. There are plenty of people on this forum trying to spread FUD on various topics, including this one, and one of the methods seems to be by asking "innocent questions" like this.
but I just wasn't sure if (a) I was missing anything and (b) if there's any merit to having a smaller blockchain size.
Smaller blockchain would mean less information is stored and from what I know all the information there is important, or some sort of compression for storage and transfer. But compression would bring no real benefit (HDD is cheap, remember?) and it would mean a need for more computational power here and there (while some run nodes on Raspberry Pi today) and would mean identical data size to be transferred after the initial sync ends.
This came about when I looked at what the Mina blockchain was doing. They use zk proofs to keep blockchain size fixed at 22kb but it obviously has a lot of trade-offs and can lead to problems if the full history needs to be accessed. And their archived full chain is currently stored on Google Cloud lol.
I am not familiar with Mina, but the Google cloud part doesn't look much reassuring
It's as simple: underlying hardware is advancing, getting bigger and cheaper, hence if this is not a big problem now, it should also not be in the future.
It is possible for certain compression to be used on block data or transaction size. Problem being that there is also a certain degree of tradeoff for your CPU as well.
It's interesting that we both thought on compression. But I don't think that it can make that much of a difference...
And yes, I agree that the size can scare the users. But on the other hand those who need 1h for sync at each start don't matter that much for decentralization, right? The users we need would keep their nodes running closer to 24/7...