You seem pretty moved by this discussion. What is your use case that is broken by protecting the clipboard and filesystem?
using the components in the UIKit and AppKit SDKs
Yes, if you want to provide a native feel, with native features like clipboards, and native accessibility features, use the native widgets. They usually tend to be stylable any way you want (my UI experience is with HTML, Qt, Swing, Win32, Winforms, and Gtk; I'd be very surprised if Android and iOS don't support widget styling). Just like on the web, it's a big problem when people reimplement a text input box from scratch.
operating systems should not support programmatic access to the filesystem.
This is the direction desktops are going, and it's where Android and iOS started. I shouldn't have to give a chat app access to all of my photos, videos, music, and documents just to let it download messages. And to upload a photo, both Android and iOS provide system file pickers. Desktop/laptop OS sandboxes should also provide file pickers to give an app access to one file or one directory.
An app doesn't need to access my clipboard until I'm trying to paste something in that app, or I know that it does something useful (and nothing nefarious) with clipboard snooping. It looks like iOS has provided clipboard notification events for different media types so that apps can show a Paste button without having to read the actual contents until the user is ready.