i guess removing unused rules on deployment would reduce the file size. But a few kb is not much today - with auto playing hd videos on Facebook et. al.
There's a big difference between a video that streams in while the user watches it, and all the styles and scripts that are needed to render the page itself. If the former is too slow the user just keeps scrolling or the player switches to a lower quality stream. If the latter is too slow the user will just close the tab and move onto something else.
With 12,000 kb/s the user will hardly notice the difference. You could add the CSS needed for the first render on the document, and it would save you a round-trip, and with HTTP2 you can send the CSS file together with the document. CSS files can however be cached so the few kb shaved off will only be saved on the first page load. If it's a common file, hosted on a CDN it might already be cached. If you are however worried about bandwidth usage the lowest hanging fruit are the binary files such as video,images, and fonts, then JavaScript trackers and frameworks, then the CSS and further trimming the content by getting rid of unnecessary markup.
Your bandwidth numbers are … extremely optimistic … unless you're only targeting business users at large companies. Worse, that's the wrong number to care about: what impacts user-perceived performance far more is latency and that's where something render-blocking like a huge pile of CSS really matters.
If you care about people on wireless connections, with less than perfect fiber connections, etc. a 500KB CSS file is going to add seconds to the total page load time and users will see it more often because the size will get it evicted from small caches more frequently. HTTP/2 won't help because the entire CSS file needs to be transferred before the page renders.
With HTTP2 you can add files to a request, if the user requests index.htm you can also send style.css in the same response. Versus the user first requesting index.htm, parses it, then request style.css. It's a pretty new feature, and will help a little bit with latency as it can save a round-trip.
Wireless connections have had bad latency, but it's getting better. 15 years ago you could get 200+ ms latency on WiFi. today we are down to around 10-20ms. 15 years ago we only had 100Mbit fiber. If you live in a city today you can get 10Gbe.
Meanwhile there are people surfing using satellite up-link, or very poor GSM, so there are strong contrasts. But they probably wont bother loading any CSS (which makes semantic HTML important).
You're assuming roughly a 50MBit/sec connection. What about people on mobile connections or in regions where 1MBit are barely achievable? Drop them over the edge? Ignore them? Might be a valid decision for your project, but for some people, bandwidth still matters.
