I'm sorry, but I believe your argument is extremely weak.
The Nintendo/Game Boy analogy doesn’t hold water. Nintendo doesn’t give you a filesystem on the Game Boy, but it certainly doesn’t stop you from implementing one yourself. Nintendo doesn’t include a filesystem because that’s not part of the Game Boy’s platform model; it’s a console with fundamentally different goals and constraints. If you require a virtual filesystem to load assets for your game, Nintendo _will not_ slow your cartridge ROM down.
Windows, on the other hand, has always shipped with a general-purpose filesystem and encourages developers to use it for data persistence, caching, configuration, and more. In fact, the Win32 API is deeply file-centric. Even the OS has its own hidden virtual filesystem.
Windows is a Unix-inspired CP/M derivative, and both lineages are strongly file-based. In fact, when Windows tried to replace the filesystem with a database in Longhorn, they failed spectacularly, and only a few pieces of that design are left today. What still exists, however, is a filesystem optimized for storing files.
Suggesting that developers are "in the wrong" for relying on the filesystem on an OS that has always promoted it is like blaming drivers for expecting roads to be usable. We’ve been building software on Windows that reads and writes files for decades, with Microsoft’s full blessing.
If Defender or related tooling starts punishing valid, decades-old patterns like using a folder as a key-value store, that’s not a failure of developers to "understand Windows". It’s a regression in the OS, or at least a poor balance of heuristics.
We absolutely should question Microsoft’s design goals if they break longstanding, legitimate use cases without offering workable alternatives. Being dominant doesn’t make them immune to critique, especially when their changes have real-world consequences for maintainable, cross-platform software using well-established techniques.