I had read previously from an unverified SQL Server engineer that the thing they wanted most (with Linux support) was proper containerization (from a developer perspective). Apparently containers on Windows just don't cut it (which is why nobody uses them in production). Take it with a grain of salt though.
I don't think they'd ever admit that filesystem performance was an issue (though we all know it is; NTFS is over 30 years old!).
It's my understanding, having done benchmarks on file access on Windows, that NTFS itself is not the problem. It's old, but the revision of the on-disk structure that we use today hails from Windows XP, and it's about on par in terms of feature parity (and backwards compatibility, given that I can still read native NT 3.51 volumes on Windows 11) with ext4.
A lot of the weirdly bad performance comes from all of the machinery that Windows wraps around file access for things like filter drivers. As long as you don't, say, indiscriminately follow every CreateFile() with a CloseHandle() and instead treat handle closure like garbage collection, you can actually eke out pretty good performance.
That all said, yeah, Windows containers are less than great for what I'd argue is one strikingly glaring flaw: Docker container images are built from smss.exe upward. That makes them not immediately portable between ntoskrnl.exe releases.
It's just easier for everyone involved (outside Windows GUI clicker admins) if it runs on Linux. Containerization is easier, configuration is easier and operating system is much more robust.
Operating system can be more robust, depending on admin skill. Let idiots configure and operate your rhel and you may not get those five nines.
There are costs to it, in the form of architectural baggage and slower iteration, but what windows brings to the table is a deck swept mostly clear of footguns. That can give you a different form of robustness.
I don't think they'd ever admit that filesystem performance was an issue (though we all know it is; NTFS is over 30 years old!).