I don’t grasp your concept of a big CSS load, but I’ll play along. I’m not sure you even try to make a valid point, since you don’t give out any viable alternative solution, but…
To minimize data traffic, you suggest something like this: browser sniffing/device width detection and sending just enough CSS (along with “just enough” from other resources) for one page alone. This, following your smaller CSS file logic further.
When the user switches from portrait to landscape or vice-versa, bad UX: waiting for additional resources to download, render again.
When the user goes to another page, bad UX: waiting for distinct additional resources to download, along with the content, render again.
Can you spot a bad pattern here? You’re thinking distinct pages, when you should be thinking entire websites.
Also, media queries are not for traffic control, are they? Why would you hold that against them beats me! Reusable, cached resources make for inexpensive traffic and good UX.
As a side note, CCs were not adopted across UAs for a reason. There is no need for them. Aside the “repair me” reason for bad UAs.
<hr>
… or you could build a m.* version for a your page. This is the only other viable (really?) solution we have. You’re pro that?
<hr>
Let the user worry about data plans. You worry about things that regard you: reusable, cached, well thought resources… and the best UX (which means media queries also).
A CSS file being so big that you have to worry about data traffic means you have a bad CSS, not that the user has a cheap data plan. This goes for images, JavaScript code, markup also. Meaning it’s not the fault of media queries!