Please read the proposal, as it tackles all your points mentioned. Also, in the original discussion about this change, the “accident” was more deeply discussed (though the result is more or less what is written in the proposal). Anyway, to still provide a specific response about your points:
It was accidental that it became a dependency on the whole operating system, including for target audiences more vulnerable to attack scenarios mitigated by ptrace_scope.
This change is an important security feature that mitigates an attack realistic for many audiences, and it is a consensus of the kernel community, and shared by several distribution communities (at least those I checked; e.g. Arch and Ubuntu) that it is important to keep: given the limited availability of packages on Fedora (especially concerning proprietary), but also potentially our issues of some packages being not updated for sometimes years without users knowing, it could be argued that our users might be more vulnerable than some others, but at least the same. This is much about users passwords, credentials, personal data transferred, etc.
It is undesirable, if at all, only for one target audience that does not make the majority, and even for people using gdb I would not presume that all of them want this feature to be disabled permanently, especially as this can be one command before and after using gdb in a related environment. The decision should be theirs. Also, don’t forget the “common assumption” mentioned in the proposal that is usually propagated when users ask how to remove packages or when they complain that too much stuff is installed by default. Most users exercise this intuitively → they might test gdb to see what it makes, maybe just out of curiosity, and then leave it - assuming it does nothing except using some space.
Such a package, even if we had a means to explicitly ensure it is just installed with gdb or strace, disables an important security feature that aims to protect them and their private data, systemwide permanently, and people are not told about it.
Keep in mind we bought ourselves intentionally average users as target audience, any many of them depend on such security measures because installing third party stuff is widespread and knowledge often not that high to understand implications, that is why we thus also brought us the responsibility for some security by default.
That would be nice, but unrealistic. I am open to alternatives though, but I am not sure if ptrace_scope can be enabled for gdb/strace on user level the way we need it without effectively disabling it. Documentation remains the sole solution I can identify, and the earlier bug tickets about the issue show that affected people were seeking immediately documentation, but nothing was there → I read the bug tickets the way that if documentation would have been available, the tickets might have not been opened (that’s why I also want to mention the issue in SELinux troubleshooting pages with a link to the actual troubleshooting page about the issue, given the assumptions of affected users in the past when searching Docs about it). We have to do better this time, that’s why I added the obligation to my proposal to create the dedicated troubleshooting docs page about this if users of gdb and such provide me with the mentioned information (plus updating the SELinux Docs troubleshooting page to mention and reference it).