Twinpigs If you start going down that route, there are plenty of ways distros and software developers "waste" space for convenience, performance, and safety.
- Shared Libraries There's no guarantee that every function is used by any or all of the programs installed, even collectively. But by leaving all of those functions in, we avoid compatibility issues, especially with non-packaged software.
- Scripting Languages The source code for these programs is often larger than the equivalent binary in a compiled language. But for many, the time spent compiling code during development isn't viewed as productive, which is why they prefer these languages, despite being larger.
- Locales Most systems are single-user or shared by users in the same geographic area, so there's really no need to have all of the locales under the sun installed. At the same time, some locales are required as a fallback when translations aren't available. Figuring out which are needed is not a trivial exercise. Asking the package maintainers to figure this out requires a degree of skill they likely don't have or time they are unwilling to dedicate to maintenance.
- Verbose File Formats For every kind of data, there exists an optimal binary encoding which takes up as little space as possible. But sometimes you want files to be human-readable, to make development easier or for the end-user. Sometimes you can't justify the time to develop an efficient binary format because you know the data format will change frequently. Either way, these files end up being significantly larger than necessary.
- Uncompressed Files There are many files we could at least compress to save disk space, but we don't. Sometimes the time required to compress/decompress is too much for the application. Sometimes compression algorithms are expensive and we want to save battery life. Sometimes users or maintainers need to be able to easily access or modify these files without dealing with compression.
- Swap Space Strictly speaking, you don't need swap at all. But when you have it, there are a couple of nice features it brings to the table. First, it allows memory usage to burst passed the maximum RAM for the system. This prevents OOM hard-locks where the system freezes and can't recover. It also allows programs to burst quickly to higher memory usage, without invalidating other cached pages since those pages can be moved to swap temporarily. restoring these pages from swap is almost always faster than having to reload the data from storage.
- Log Files Technically speaking, logs are used much less often than not. They are often encoded in inefficient human-readable formats and are rarely configured to be cleaned up at what most people would consider to be a reasonable size. But when you need to figure out what went wrong on a system, there is no substitute.
- File Caches Web browsers, package managers, compilers, etc. rely on file caches to speed up their operation and often to reduce their need to use network bandwidth. Strictly speaking, you don't need these files at all for the program to function. It could always fetch or regenerate them. But the cost of that has to be weighed. Having to refetch files from web servers means more network bandwidth, network load, more load on the web servers, and longer page load times. All while exposing your system to even more time connected to remote machines which isn't great for security or privacy. Having to regenerate build artifacts when compiling programs means that compilation takes longer. In both of these cases the user has to wait longer and their machines have to expend more power to do identical operations.
You seem to be thinking of storage space as this finite resource that is lost as soon as it is used. On the contrary, storage is significantly more reclaimable than other resources. It can easily be overwritten with other data. Drives can last for several years without failure, even after be overwritten hundreds of thousands of times. Most of the components in these drives can even be recycled to make other things.
