Self-contained single-file assemblies do not require this. Simply specify corresponding properties in .csproj or as arguments to dotnet publish (-p:PublishSingleFile=true --self-contained -r {RID}) and for pure C# projects you will get exactly a single executable file that does not require any dependencies to run except what is expected to have on the average target system (glibc, openssl, etc.).
Other than that, it seems that due to other languages, there is misconception that Native AOT is a panacea that is superior in all areas to normal single-file executables that use JIT. In fact, on average, JIT produces faster code because some optimizations are only possible with tiered and dynamic PGO compilation.
You're right -- there are a lot of tradeoffs here, and one solution isn't necessarily better.
What Native AOT offers is very small binaries, with very fast startup, and smaller working set. It can also be integrated as a standalone static/shared library into a different application.
Self-contained apps don't require AOT compatibility and may have higher peak throughput (as you said, JITing can be faster in some cases).
It's up to you and your application whether the trade-offs make sense.
Other than that, it seems that due to other languages, there is misconception that Native AOT is a panacea that is superior in all areas to normal single-file executables that use JIT. In fact, on average, JIT produces faster code because some optimizations are only possible with tiered and dynamic PGO compilation.