Amusingly enough ... The rates there are, in fact, significantly slower than what plain old Bitcoin developers. Bitcoin dev's probably should make the syncing status print the number of inputs per second being processed.
But being able to barely keep up means that if you fall behind for even a moment (say, if your connection drops... or if miners get lucky and mine a bunch of extra blocks) then you will _never_ catch up. Operating anywhere near the limit of your processing rate is non-viable for that reason.
You need to be able to process many times the network's capacity so that you can catch up in a reasonable amount of time.
Sure, but OP said 2GB. A node able to process 4GB blocks would be able to sync at 2x realtime. Most people who run nodes will probably bootstrap new ones in the future anyway and most people don't need to run full nodes in the first place (the majority don't do so today and haven't since light wallets became available).
To get back to reality, I don't think any sane person has advocated for anything close to a 2GB blocksize cap at any point in the near future. Bitcoin Core uses a maximum 4MB block weight and Bitcoin Cash uses a 32MB cap currently. This cheap VPS could sync the entire Bitcoin (Core) blockchain from 2009 to present in less than 12 hours. The biggest block size cap (not full blocks, the cap) being tested seriously is 1GB. I'm sure you know all this, though.
But being able to barely keep up means that if you fall behind for even a moment (say, if your connection drops... or if miners get lucky and mine a bunch of extra blocks) then you will _never_ catch up. Operating anywhere near the limit of your processing rate is non-viable for that reason.
You need to be able to process many times the network's capacity so that you can catch up in a reasonable amount of time.