Do not be fooled by appearances. If you are watching a game and the corresponding archive file is very small, eg. 1MB, it is not always said that the game you could download is short, or with poor graphics.

For example, I developed a video-game, BounceB-Revenge, which occupies just 1 MB but is very complex and long by finish, and with good graphics.
In defining the levels I used a mapping technique similar to that used by JPeg file compressors, which allows you to define rectangular, stackable, and renderable pieces in real time.

This is surprisingly very important for mobile. A lot of people with mid end phones are struggling with internal memory, and apps (especially games) that are even 15mb+ can be very repelling for these users. 

Depends on what you are trying to do with your project. The demoscene has made some amazing projects fit into insanely small filesize using procedural methods, including a full FPS [kkrieger] with procedurally generated textures running out of a 96kb executable, a 4kb landscape flyover with motion blur [Elevated], and a beautiful space flythrough in 64kb [Mercury - Fermi Paradox].  There's also a UDK level made with just a single 512x512 texture map.

So extremely efficient use of assets is possible.

But what these people are doing, is it recommended? I'd argue that it's unnecessary - interesting, sure, with a certain novelty factor, but most AAA games on Windows are in the 1GB range for a reason, namely that recent generations of PCs can handle that sort of file size.  And if they can handle it nowadays, why not take advantage of that and push it for the best graphics quality possible?

The other argument, aside from hardware and download filesize limitations, that's been put forth in favor of procedural or highly minimalist graphics, is not needing to hire artists. That's questionable, however, as procedurally generated art rarely looks as good as intentional, artist-made art, and to generate procedural content isn't any cheaper given the extra time required in programming, that negates any efficiency gains made by less work for artists.

My take: this focus on efficiency in storage used is practical only up to a point; yes, it matters, and you certainly should aim for as low a filesize and as minimal hardware requirements as you can, unless that means severely compromising the quality of the finished project.  

if nice graphics and animation are important to the appeal of your project, and the platforms you're aiming for are desktop platforms, it may be worth allowing for some more file size.  I personally am an artist and not so much a programmer, so my projects will tend to emphasize the atmosphere and aesthetic style that are my strengths, and not so much complex interaction, especially early on without any other team members.  So if the visuals are key to my project's success, and a strong asset for me, then it makes sense not to slash filesize to the point where that appeal is compromised.  It's all about finding the right balance, and there are rarely real rules for this, mostly just guidelines.

Would I like to have my current project (Miniature Multiverse) under 10MB? Sure, there's an appeal to doing so, but IMO I'm more concerned about its quality than its efficiency, and it's important having some beautiful visuals to show on Itch.IO for promotional reasons if nothing else. If your project looks great, that absolutely gets you more attention, more views, clicks, downloads, sales.  That matters more to me, than keeping it extremely lean and extremely efficient.  Those sales could be vital to my ability to effectively expand not only that project but also a long list of others down the line.  It could make it possible to even someday hire musicians, programmers, etc, on short-term tasks, to solve specific, particularly tricky things I want to do later, which couldn't do as well myself.

So I would say that keeping filesize down to tiny levels is good only to some extent, under some conditions for some developers and some platforms.

This is an exhaustive response that includes all aspects of this problem. Thank you matthornb for the time you've us devoted !