Hi Jay,
welcome back to the Forum 
In short, I think sysadm_u is the confinement that is most interesting for most Fedora use cases (but you have to enable a boolean in advance: setsebool -P xdm_sysadm_login on → this allows sysadm_u to use the GUI). Be aware that sysadm_u does not add any privileges but only restricts some compared to unconfined_u. But it introduces the majority (and the most important) advantages and security measures of confined users while keeping possibilities used by many Fedora users available.
There is a recent topic that might answer some of the underlying questions of your issue: How to enable SELinux user confinement? What to consider? (only the first two posts are interesting). With regards to that …
I don’t know how gnome-boxes itself is constructed since I don’t use it, but this likely relates to the case of cockpit I mentioned in the recent topic. Be aware that staff_u is intended to minimize capabilities of a user and restrict it fully into its own space. Using virtual machines has many outreaches and often does not work when fully restricted. This is explicitly intended. So within the staff_u account, you can only use virtualization applications that do not by default establish connections/outreaches for administration. This includes cockpit, but even cockpit can only be used with the credentials of the user that is logged in (so if you start cockpit in the browser of the staff_u user “Jay”, then you can only log into cockpit with the user credentials of “Jay”). And the administration possibilities will be restricted, too.
Because staff_u is more desgined for corporate realms, where any user shall have limited access (which includes attached USB devices that are not explicitly profiled for the user), I think sysadm_u should be the goal for Fedora for now. The approach I currently have in mind is to combine sysadm_u on one hand, and use other means from the Confined Users SIG (those proposed by siosm) to then mitigate+disable su & sudo at all when/where applicable. This is why we consolidated the two areas. It will be then up to the users if they want both or only one of the two measures.
What could be interesting for you. although I am not sure if it will be a “sufficient experience” for you, is to combine the staff_u user account with the sysadm_r role (“r” at the end, not “u”): - problem: this is not designed for use in graphical environments, and thus might cause issues when used to run graphical applications through, e.g., sudo <app>. But feel free to make a more sophisticated test and let us know if that feels an acceptable solution for you.
With regards to the issues you focus on, I assume user_u would be widely the same, except that even sudo would be blocked (imho, in the use cases relevant for Fedora, I assume that beyond sudo, user_u and staff_u are much alike with only minor differences). But I agree that user_u is unlikely to be useful for you, too 
I have not yet tested it explicitly, but I think you need to implement the sudo with the sysadm_r role as mentioned above to achieve that. Keep in mind: staff_u shall also offer mitigation when an account is captured or abused, and it is explicitly intended to limit the user from outreaching to other users or beyond (which would be the case with the root journalctl). If you want to remain with staff_u, I suggest to use sysadm_r for that (and for the worst case, keep the root account with unconfined_u and different credentials active).
I saw that before in my initial “screening” of the different spins. That seems indeed like a bug in the profiles that still exists.
If you are interested, feel free to open a topic in the Project Discussion category with the security-sig and the confined-users tag, provide elaboration of the issue (what occurs under which circumstances, and the exact details of the Fedora you use, e.g., Fedora Workstation 40, no third party repos, up to date as of now), provide two types of outputs and let us know the exact time when you provoked the SELinux denial. Here the two outputs:
ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
journalctl --no-hostname --boot=0
Feel free to further anonymize the output. Also, it would be ok to limit the output of the journalctl command to an extract of the time of the very issue plus 30 seconds before and 30 seconds after. However, if you provide only such an extract, please add additionally the output of uname -r.
The same as above: Feel free to open a topic in Project Discussion. I cannot reproduce this to be honest. I was using staff_u on KDE some time, and although there are open issues (while some are intended and make staff_u unattractive for many use cases), I have never had that issue. However, I have not yet tried staff_u on F40. Could you share the exact details of your Fedora that has this issue? E.g., F40, KDE Spin, no third party repos, up to date as of now, etc. ?
We are happy to help, and to get your incentives. It is data we can use to improve SELinux. You already shared some data we have not had before. Our SIG is to enable this type of collaboration and bring all stakeholder groups together in order to facilitate a “joint evolvement of members in their knowledge”. Welcome to the SIG 