When talking about the file system, I'm referring to the local file system, not an external solution that acts as a bridge. The Files.app and iCloud Drive are workarounds to get past sandboxing. If that works for you, terrific, but that introduces a level of indirection that wouldn't be needed without the restrictions of sandboxing.
My point is that it’s a layer of indirection that’s largely invisible to both the user and the app these days. It doesn’t really matter if you don’t have access to /usr/bin or to /var or if the file tree starts in a directory called iCloud Drive instead of C:\, Macintosh HD, or the desktop (which it kinda did in Mac OS Classic). And sandboxing offers a great deal of protection to the user, too, it’s not all downside. A rogue application can’t access your crypto wallet, for instance, if the crypto wallet is in your application’s sandbox. It’s also a critical aspect to enforcing the permissions API, an app has to ask permission instead of being able to surreptitiously access contacts, photos, etc. through the file system. (Which is probably why it took Google so long to introduce a similar approach to permissions on Android, since apps expected to have free access to the file system.)
In earlier versions of iOS, there was a real cost (in terms of the user experience, app interoperability) to sandboxing that just doesn’t exist anymore. And, indeed, sandboxing allows for a more logically oriented user-facing virtual file tree layout than the actual file system, no need to be confused by things like the AppData folder in Windows, /etc, /opt, /var, /dev in Unix-like OSes (including iOS’s native file system). And it’s better than just hiding those folders and otherwise keeping the file system intact, since the hierarchy can better reflect how the user interacts with the system. I’d say that, for most user tasks on iOS, there isn’t really a cost in terms of sandboxing and plenty of upside, at least in modern releases of iOS. Hiding implementation from interface allows changing out one implementation for another and is generally regarded as a best practice in software development. In terms of user interfaces, failure to do so can even result in fragile user interfaces that break with the slightest backend change.
It’s a lot like computerized transmission on newer cars over traditional manual, it’ll definitely outperform your manual input, but it gives a wholly subjective feeling of lack of control if you happen to be used to the sensation of driving manual. It doesn’t have the same feel of responsiveness, sure, but you don’t really need that if your goal is to get from A to B. And, if your goal is to feel conceptually like the machine is an extension of you, that you have direct control, buy a car with a traditional manual transmission. Likewise, if you want that sense of “I have total control of the underlying system”, you should really be using a desktop computer (or maybe a Surface Pro for Windows or Raspberry Pi for Linux) and something like Arch Linux, anyway. An iPad would be the wrong device for you.
Fundamentally, an iPad running macOS would cease to be an iPad. It would be a macPad, even if they called it an iPad. I’d imagine that, circa 2008, Apple likely did have a netbook project that didn’t get very far into the development process. It might have resulted in the OG MacBook Air. I imagine they found that shoehorning macOS into a sub-11” display compromised the user experience dramatically. And Apple won’t change the software that runs the iPad Pro without also changing the software that runs the iPad mini, so an Apple tablet natively running macOS likely wouldn’t be an iPad. (Hint, it would be Macintosh branded, all of Apple’s Intel Macs, except for the XServe, have had Macintosh branding. The only “Macs” never to have Macintosh branding are the PPC and Intel XServe, the 68k and PPC PowerBooks, and the PPC iBooks.) Even if it were branded as an iPad, on some level, it wouldn’t be (especially if the iPad mini continues on with the iPadOS).
