When a typical application spends multiple megabytes just for the webfonts and logo JPGs on the front page, I don't really care whether my application bundle is 200k or 500k, though. I care more about productivity.
Now, this clearly needs SOME boundaries, but let's not start a whole "Electron" thread again :)
I think it's still worth paying attention to size of the JS download. If you download 500k of JS, it means that after ungzipping it, it will be 2mb or more. Your browser needs to parse and execute that code, which also takes time, and it impacts the user experience.
Also it's easier (at least from developer's perspective) to deal with a big image than to deal with big JS codebase. You can't just replace it with something smaller, you often need to spend a significant amount to shrink it.
Definitely, this is also why it's important that Angular is making strides towards reducing the total download size. This is, in fact, exactly what is happening with this release (and it will only improve when Ivy is released).
This does not mean the frontend community should continually be bending over backwards reinventing wheels just so the claim can be made that a certain package is now "only 1.6k GZipped!", imho.
Is there anybody who assumes networks are fast enough and immutable caches are a thing but parser is the bottleneck? They would bundle everything into a single js but minimise parsing costs.
The bundle size is now much better, and will only get better with Ivy. Also, I don't think it makes the most important comparison point although it certainly is one to consider.
Most websites on the internet load several megabytes of Javascript.
For a full-size SPA, I think Angular is a great choice, but for incremental use cases like adding some interactivity to a mostly static page, it's still not the main use case, although that will change with Angular Elements.
It's a different story when your application is huge and mostly made of batteries. ;- )