I cannot run Bitcoin-qt during the day because I'm on a tethered 3g connection and do actually need to use most of the available 5-150kbps of bandwidth during the day.
The absolute maximum long term average bandwidth pulling the blockchain can take is about 13.3kbit/sec. I'm not sure what the source of your issues is it may be due to bandwidth used relaying blocks and transactions to other peers, but you do have enough bandwidth to stay synchronized at least to within a couple blocks of most current.
Claims like "I am afraid that any remedy will only push out your timeline running a full node a few months or a year. " are just factually untrue on the data that you've provided. And, if the "business of running a full node, (...) become(s) as serious as it is now to be a mining pool operator" then bitcoin will be dead and pointless, because running a full node has no _business case_ as it can't be directly monetized and there is always an incentive to let someone else take the cost if the cost is great enough to not be inconsequential. If fairly few parties run Bitcoin, then Bitcoin would fail at its purpose of requiring less trust than the commercial banks of democratic nations, as their trust model is stronger. Fortunately, the design of the Bitcoin actually prohibits this loss of decentralization from happening Blocks have a maximum size (and the size of blocks nodes will create is further artificially constrained by current implementations), and this bounds the cost of running a full node. This size can not be increased without a hardfork of identical technical complexity to changing the supply of coins so to pull it off it would have to be utterly uncontroversial, and presumably people will always stand up to insist Bitcoin remain practically decenteralized. The maximum cost is still a bit high relative to current hardware, but it won't be in a couple years with a few more cranks of the silicon and storage scaling laws.
That said, for a mobile connection a thin or lite client is the obvious thing to use. Ideally, you could run one behind a full node that you have absolute trust over (E.g. because you own it), and then you don't even need to worry about the potentially reduced trust model involved.
But it would still be interesting to figure out why your node isn't keeping up.
Yes, increasing the block size limit has identical technical complexity to changing the supply of coins - that is, no complexity at all. Changing the supply of coins has economic/social complexity - people signed up to Bitcoin on the premise that the value of bitcoins are maintained by their scarcity, with a specific inflation schedule. Changing that will destroy the Schelling point and nobody will agree to it. On the other hand, nobody signed up to Bitcoin on the premise of a specific block size limit, so when it becomes necessary the change will be uncontroversial and fairly easy (change the client to have increased size limit starting from block 270,000, giving everyone half a year to upgrade).
If Bitcoin is ubiquitous there will be about 10K Bitcoin payments per second. A block size limit of 1MB will allow about 1 transaction per second. This means that 99.99% of payments will be outside the blockchain. So you will have this beautiful decentralized system that everyone can run but nobody can use, they will have to resort to 3rd party alternatives with various trust requirements. There will still be some benefit from having Bitcoin as the foundation, but that diminishes the more expensive it is to actually do a real Bitcoin transaction.
It's more likely the block limit will be raised eventually to about 100 MB. People won't be able to run a full node on their cellphones, but any enthusiast will still be able to do it on a PC, and it will allow for 1% of payments to take place on the blockchain. It's still sufficiently decentralized and is now also useful.