Let's take the example of London Underground's Wi-Fi. It's only available at platforms, not while the train is travelling between stations. When the train arrives into the station it will stay there around 10 seconds. 5 seconds of those are wasted by the phone finding the network and authenticating to it, which means you've already got only 5 seconds before the train goes away and the connection drops off. During those 5 seconds you have lots of apps in the background (push, e-mail sync, background app refresh, etc) that are all fighting for around 1Mbps of bandwidth.
There's also the issue of failing gracefully. If CSS or image loading fails the browser will still display the bare HTML and the user will still have their content in a consumable format. If JS fails to load in an SPA the page is unusable and often shows just a blank screen. If SPA-initiated requests fail it's up to the developer to handle the exception and offer the user a way to retry instead of just giving up and waiting for a page reload.
Broken images and incorrectly loaded CSS can also break pages and make them unusuable so where do we draw the line?
I do get your point but on the other hand many sites are using JS frameworks for good reason and 5kb is absolutely nothing to improve the user experience. You really can't complain about the size of a 5kb javascript file in this day and age otherwise let's just revert back to HTML 2 or 3 to cater for all edge cases.
Google's logo, one word, 4 colors, is 14kb.
To have a library that gives you a better foundation to build a website on be 5 (actually 3) kb? In what universe is that a bad thing?