Older games built on the Quake{1,2,3} engines use hardly any network bandwidth. Most Bad Company 2 games have only 32 players, which is hardly bigger than Quake1. What's going on that's so much more bandwidth intensive?
Also the need for more detailed positional/vector data for much more complex physics simulation, which also requires both a higher resolution of updates to function realistically. Additionally, fast moving vehicles with more delicate control/handling, such as fighter aircraft, also a require higher resolution of updates so that you can actually fly them without crashing due to the feedback loop of perceiving jerky/delayed movement and input response. Prediction can help to smooth this out.
Additionally modern games use things like physically simulated projectiles (think bullet drop[1]) with collisions calculated using mesh-based collisions instead of simple hitboxes, over much longer distances, so there is a need for prediction as timing is more of a factor. Quake 1, 2 and 3[2] use the 'hitscan' method[3] of calculating whether a bullet hits its target, which is instant and calculates a linear trajectory, which has the side effect of making it easier for players to adjust to lag (basically any difference between the player firing and the hit registering is network lag, and should be more or less consistent).
Finally, two slightly different issues that have become apparent in recent years are automatic match-making and local servers (ie, the game running on one player's console). Auto matchmaking is often fairly shitty, meaning that (on average) players end up playing on servers to which they have a higher ping time than if they had chosen the server from a server browser (something that is sadly becoming rare in today's games). The phenomena of local servers, on the other hand, puts pressure on the total available throughput, rather than ping time, as the player that is hosting likely has more limited outgoing bandwidth than a dedicated server might.
[1]http://en.wikipedia.org/wiki/External_ballistics#Bullet_drop
[2] only for some weapons, a rare exception for the time
It seems that could pose a security risk to extremely savvy users (as the game state includes things they shouldn't be able to see, like the opponent's units in Starcraft, and one might be able to make a program to inspect the state of the running game client), but I can imagine encryption and obfuscation dealing with that sort of problem with very little overhead.
Ideally, FPS would run two versions of the game world, what happened, and what the players see, with more information being sent about what happened close to the player helping the version that players see be more accurate. And continuous updating of the version players see based on predictions from the "real" version of the game world. But, getting that working would be extremely demanding and reduce the games ability to do physics in real time etc.
PS: Game developers may be smart, but as a rule they have less experience than you might think. Short burn out cycles keep the industry from evolving.
Also, don't underestimate your users. Encryption is irrelevant, they'll hack into your program's process space and read the stuff after you decrypt it, and obfuscation is at best problematic for the same reason. For a AAA-class game, assume all users have access to all data on the client at all times and you'll not be far wrong. Sort of how like in the encryption world we just assume that the attacker knows the algorithm already.
You can make it harder to do (Blizzard's Warden, Valve's VAC) but people will get around any technical barrier you put up.
Fog of War (maphack) would be a more apt example, you only send the client what it is possible for them to see. Speed hacks are another that can be stopped, the client asks the server if it can move X units, the server responds with how many units the client moved.