Also worth noting that it's ~37kb over the wire, applies to the whole site (where it is much more thoroughly used), and contains a bunch of svg icons that don't need to be loaded in separate requests. If anything, that reinforces to me how well considered it is!
I don't want to necessarily argue with OP's CSS file but there is a teachable moment here. We make a master CSS file because we don't want to serve bunches of CSS files per page. The constraint we want is:
n << 100
There are other solutions besides n=1 that satisfy this inequality. Serving 2 CSS files per page does not introduce substantial latency over 1, even on HTTP 1.1 user agents. Once you get to 4 you start to cause some problems, but 2 is barely noticeable.
CI/CD can fight your CDN by reissuing every asset on your website on every single publish, causing all of your visitors to soak up bandwidth at the same time. If you name your JS and CSS bundles based on the hash of the contents instead of prefixed with a version number, then many publishes will reuse the same assets, except that doesn't scale so the bigger the website the more evictions you'll see. But a site bundle with a per-page or per-subject matter bundle does scale, because targeted fixes often won't affect your home page.
And this approach may or may not be better, depending on usage patterns. Code splitting or even inlining may benefit users who tend to view only one page then move on. A single file loaded and cached upfront will tend to benefit users who stay on your site to view multiple pages.
In either case, splitting atomic CSS is probably more complex to get right because of ordering, and possibly more inefficient for everyone as well.
