I did write monitor, assembler/disassembler in Z80 assembler for a tiny home-built Z80 machine some 25 years ago.

I have a huge number of features with serial ports, SPI, GPS processing, alarm handling, real-time clock, ... in 4kB of assembler for Atmel Mega48, ...

In this case - any processor that would have 64TB of built-in RAM would not be called tiny for quite a number of years to come :)

M$ do set the criteria for software development. Their OS do consume a huge amount of memory before any third-party developers gets a chance to add own applications. And do not forget that M$ is a major supplier of development tools, courses in software development, application notes, ... which means that they in a very large part affects how new Windows programmers will learn their trade and will design their systems.

If a tool produces a 1MB large "Hello World" application, then the developer will not be surprised if a "full" application consumes 10MB. If an old Turbo C compiler produced a 4kB "Hello World", then it wasn't unexpected that a real application consumed 200-400kB. If the assembler tools could produce a < 100 byte "Hello world", then it isn't surprising when the developers manages to do huge applications (function-wise) in a couple of kB.

On the other hand, sometimes "big is beautiful" can be true. Sometimes, it is advantageous to take a larger application just to get a lower developent cost. An example is the use of associative arrays to index information. An application can then directly load data from a database and store in a sorted array - even if the sort key is a text - and directly lookup and work with entries.

But the reason I regularly do kick at M$ is that their tools and development concepts seems to always produce large applications - even when not giving the developer any real advantages in the form of quicker development times. It seems like they release new tools without somewhere asking the questions: Will this require a hw update to give expected performance for existing problems.