The threats are completely different.
Tor Browser has a much larger attack surface (it has far more features and functionality that could go wrong) and it's not written in an memory safe language (if features or functionality do go wrong, the potential for exploitation is far greater) where as OnionShare is written in python which is memory safe and has a far smaller attack surface and is designed and intended for a single task, with a far smaller code base.
There is similar hardening in place. This is applied through AppArmor, the same kernel access control module used to enforce Tor Browser's restrictions but it was decided to allow sharing of almost all content from the amnesia user's home directory, it's easy to imagine scenarios where users wish to share a document from inside ~/Documents/ or a file from inside ~/Persistent/. There are some exceptions for folders that may contain cryptographic keys, logs and a few other sensitive files, e.g.:
amnesia@amnesia:~$ onionshare .gnupg/secring.gpg
Onionshare 0.9.1 | https://onionshare.org/
Connecting to Tor control port to set up onion service on port 17600.
Staring ephemeral Tor onion service and awaiting publication
Preparing files to share.
Traceback (most recent call last):
[...SNIP...]
PermissionError: [Errno 13] Permission denied: '/home/amnesia/.gnupg/secring.gpg'
Ultimately, like a lot of Tails' feature set, there is a trade off between security and usability (where they conflict). It could be more restrictive but if you made it difficult for people to use in the process, they might instead opt for a less secure alternative. An example of a more secure setting to run OnionShare from would be something like that used in Subgraph where they are run inside a sandbox and further restricted with other userspace and kernel hardening mechanisms.
The relevant AppArmor configurations are: abstractions/onionshare, onionshare and onionshare-gui.
Here is the ticket created for the review of the Tails developers AppArmor profiles: #11930.
