And today we are left at a point where the bandwidth consumption of an ordinary Bitcoin node just barely fits within the 350GB/mo transfer cap of a high end, "best available in most of the US" broadband service. We cannot know to what degree the load increase was causative, but none of the metrics had positive outcomes; and this is a reason to proceed only with the greatest care and consideration. Especially against a backdrop where Bitcoin's fundamental utility as a money are being attacked by efforts to regulate people's ability to transact and to blacklist coins; efforts that critically depend on the existence of centralized choke-points which scale beyond the system's scalability necessarily creates.
The problem isn't the block data, which at the present 1 MB limit uses less than 3 percent of a 350 MB/month ISP cap. The problem is that Bitcoin Core does not provide the instrumentation and tools to allow node operators to manage their bandwidth utilization. The developers could fix this situation if they were so inclined. I interpret this situation to a question of priorities and/or lack of network performance expertise on the part of Bitcoin Core developers.
This is a valid point and for once in this debate can lead to a constructive suggestion. If the choice is between contributing 350GB for a full node and closing the port effectively contributing nothing and one has a 300 GB ISP cap then closing the port becomes the only option, even though the node could very easily contribute say 150 GB. There is a very disturbing all or nothing approach to this debate that leads to a choice between two bad options at both extremes.