It's definitely possible to build a self-contained EXE. It's not easy or the default for a number of reasons, including the fact that going back even to DOS the PC application deployment model for applications is folders full of shared library DLLs and a smaller EXE that makes use of them. (The Win32 page model was built on it.) Modern .NET excels in that, including in the classic DOS installer model of "just copy the files, no installer required (but you'll probably build one anyway for extra branding opportunities and a few bonuses)".

Some .NET versions <= 4 installed a lot of their DLLs globally in Windows and if you were exact version tolerant enough (and GAC binding magic lucky enough) you could distribute a single EXE without an installer and expect some number of Windows users it would "just work" with only the EXE (and other users you would get complex dances of Windows Updates and .NET Installers to debug). Modern .NET decided on the classic DOS style "folder of DLLs" model over "global DLL cache and DLL Hell". You can no longer assume that the output EXE can "just work" on some supported Windows machines, but can better assume that the output folder of DLLs and EXE will work as intended generally on every supported Windows machine.

Not everything is flowers and sunshine (got a couple of open issues myself... in .NET MAUI too), but whether one can build a single, compact, self-contained exe does not define the hostility of a framework or platform, IMO. .NET was conceived as an enterprise-friendly development framework and that's where it shines the most. Quick-and-dirty/mean-and-lean/distribute-and-forget development was never its forte. I would appreciate that feature too, but it's largely a non-issue.

Both replies totally misunderstand my comment.