Its your user’s local dir, so of course you are free to create files in it.
The ~/.local/share/ dir is indeed one of the issues why noexec causes issues in some desktop environments (see the mentioned KDE SIG #368 above).
Obviously the issue with .bashrc is the same, although the impact of manipulations of .bashrc might be worse in some cases.
Generally, most operating systems have a security architecture that tries to secure the user account as such so that no further security is necessary from within. This is necessary to achieve an acceptable user experience → most people would not be able to manage anything else and would get rid of any security measures at all (we saw that already in the time SELinux has been introduced: many admins just turned it off completely). The obvious outcome is that if any attacker can act from within the user account, there is not much that limits the attacker possibilities once they achieved privileges in the user account. I elaborated this in the above mentioned topic.
SELinux confined users change that (hopefully, at some point at a level that is usable by any average user). The issues you refer to fall into the same category as those elaborated in my previous post: you need a profile that fits the action you want to do. This limits the possibilities of an attacker. First, a directory has also a profile, which means that adding a new file also needs a profile that fits. Second, the major issue I see is a captured or a malicious process: e.g., for some reason, an attacker captures your browser (if you use a secure default browser, this is very unrealistic as of today!) or any application that you installed is captured/malicious (maybe from a third-party repository that ain’t sufficiently tested for Fedora or that is malicious at all) or so → the profiles of “processes” will have limited possibilities to create or change the files you referred to if there is no intentional user action involved. So again, the idea of a Mandatory Access Control (such as SELinux) to not only mitigate attacks at all but also limit the possibilities of seemingly-successful attacks so that they at the best cannot do anything outside the very malicious/captured process is “fulfilled” here.
But as mentioned in the other topic, getting into a user account on a normal desktop/workstation system is already hard because the potential entry vectors (e.g., Firefox) have on themselves strong measures to mitigate attacks and exploitation so that attackers cannot enter a user account as easily as it may sounds (e.g., seccomp). In practice, the issue is mostly that users break themselves the architecture, such as using dangerous untrusted third party software or so (at the worst giving it privileged access), and thus in practice the issue is less that the architecture is broken by attackers. But indeed, SELinux can here help to mitigate the security issues caused by the users themselves, and thus “protect users from themselves” to some extent (making things smoothly usable by average users by definition implies security compromises).
Further, keep in mind that if an attacker has physical access and the necessary credentials, the possibilities of an attacker are much higher than their possibilities with a captured/malicious process, and it is likely that you as a user (and thus in this case the attacker) will have the possibilities to create desktop files and such → it is your account, you need to be able to use it. If the attacker reached this possibility, the only remaining mitigation is to limit the attacker to the user account which has from that point on to be considered broken/untrusted (obviously, that would include to have no sudo on the very user account).
A slight supplement (I’m not sure if that is clear so far): Be aware that factual “SELinux privileges” differ from the “normal” privileges. These are two independent layers of security: every action needs to be permitted by both layers → therefore, if any of the two layers denies an action, the action will be denied at all. In the previously mentioned topic that is elaborated more deeply I think.
So, the stuff you see in the terminal when you seek information about privileges on a file or directory, such as -rw-r--r-- when doing ls -l, has no impact on the factual “SELinux privileges”. But you can get information about the SELinux labels (which in the end determine the possibilities/privileges) by adding the Z option, e.g., ls -lZ.