Humans are designed to obtain their goals while conserving as much energy as possible. As a rule, people will always take the lowest-effort route to get what they want. At a macro scale, this can only be counteracted by designing systems that strongly discourage specific low-effort-but-harmful routes, and even then, there will always be some sector of the population that doesn't grok the downside of taking the "easier" way.

I think one of the big things that has impacted SELinux adoption is that everyone has sort of seen it as a proactive booster rather than a really necessary part of a secure environment. I'm sure a lot of that is because lots of people are used to administering systems that were around before SELinux (and similar) was. For something that's perceived as a bonus point, it interferes far too often.

Most people don't realize SELinux is on until it does something really bad like stopping a database from restarting correctly or otherwise harming what's supposed to be a stable environment. When those are the stakes, SELinux does not have, or at least does not make immediately clear, a sufficient value proposition to incentivize the admin to fix the rules rather than just turning the whole thing off.

For example, to contrast with the OP, when SELinux stops Docker from doing something, the impulse is not going to be "Yay, SELinux stopped Docker from doing something dangerous! Thank you glorious SELinux!" Instead, it will be "Ugh, SELinux again getting in the way of stuff. I just need to disable that. I get enough headaches from Docker as-is and SELinux probably just isn't modern enough to handle my uber-charged stack with all of it's new-fangled features. Disabling!"

I agree with your post, except for one point: system design shouldn't be focused on strongly discouraging harmful low effort routes, but on ensuring that the good routes are less effort than the harmful ones. That is, while it can be achieved by raising the effort of the harmful routes, it can also (and might be better) achieved by lowering the effort of the desired routes. For example, if journalctl showed the relevant AVC messages when showing the log of a failing unit, it would remind the administrators they may need to adjust it. (Except actually mention SELinux in the message, nobody knows what AVC is.)