If we really needed to, we could compress assets a lot, eg with procedural generation. (Including the neural network kind.) But that would be a lot of hassle, and would probably trade run time for space.
As for code: I think shaving of bytes isn't all that important, especially compared to assets; but simplifying logic can give various benefits. However, that also takes time and is probably not worth it for many applications.
A distinction I like to make is being careful to distinguish between bloat that worsens throughput and bloat that worsens latency.
Throughput still gets better almost for free over time by general hardware improvements. Latency still requires attention.
An example: an early word processing software (I think it was part of GEOS for the Commodore 64) paid a lot of attention to keeping the latency between you pressing a key and a letter appearing on the screen low. By today's standards, the Commodore 64 was slow as molasses, so when you typed quickly GEOS eg temporarily disabled breaking wrapping words at the end of the line and just jumped to the next line in the middle of a word.
After you had finished your burst of typing, GEOS would go back and calculate proper line breaks.
Compare that with textfields in modern websites, which sometimes have a noticeable delay before a letter shows up.
GEOS's code for such latency reduction was probably incredible convoluted and messy (I am just guessing here) and made it hard to a nightmare to add new features, but was worth it back then. The modern bloated website can probably sustain a higher throughput, even without no one taking any care to optimize that. But latency is horrible.
I wrote the PC equivalent for a similar product in the 1980s and wrote some different GEOS code. It was less convoluted than you might imagine. But it was very unforgiving in terms of de-referencing null pointers and memory leaks. Instead of using a little too much memory or causing a process to crash, it would often cause the system to hang. Windows 3 (and to a lesser degree Windows 95) had similar problems.
As for code: I think shaving of bytes isn't all that important, especially compared to assets; but simplifying logic can give various benefits. However, that also takes time and is probably not worth it for many applications.
A distinction I like to make is being careful to distinguish between bloat that worsens throughput and bloat that worsens latency.
Throughput still gets better almost for free over time by general hardware improvements. Latency still requires attention.
An example: an early word processing software (I think it was part of GEOS for the Commodore 64) paid a lot of attention to keeping the latency between you pressing a key and a letter appearing on the screen low. By today's standards, the Commodore 64 was slow as molasses, so when you typed quickly GEOS eg temporarily disabled breaking wrapping words at the end of the line and just jumped to the next line in the middle of a word.
After you had finished your burst of typing, GEOS would go back and calculate proper line breaks.
Compare that with textfields in modern websites, which sometimes have a noticeable delay before a letter shows up.
GEOS's code for such latency reduction was probably incredible convoluted and messy (I am just guessing here) and made it hard to a nightmare to add new features, but was worth it back then. The modern bloated website can probably sustain a higher throughput, even without no one taking any care to optimize that. But latency is horrible.