I agree with the OP, these are annoying issues. But, FreeBSD is industry-grade OS, so it might be advisable to do things like the industry folks do them. This means:
If you do an installation for a new platform (hardware+software), in the first step you install from the public installation media, you see to get to a running OS, then you check your requirements (supported hardware+software): can it work? what is required? how to proceed to it?
In this phase one can experiment, one can change things in any way.
At some point there will be enough data to come to a go/no-go decision.
Then everything is removed again, and installation is started anew, this time with a plan.
#1 a suitable driver would have been prepared in phase1 and a bootable media created
#2 a workaround would have been decided in phase1 (or this considered a show-stopper for now)
#3 no idea, but sounds like a minor issue. (I am using mutt, but don't know "dracula-color" - anyway, the mutt config is plaintext and should be fixable)
#4 this would be figured out in phase1
#5 sounds like a normal prereq. With individual installations (outside of the ports tree) it is not avoidable to read the Installation/Readme docs provided with the software, and check/install the requirements.
Then, yes, it might be possible to make the OS behave more plug&play so that these issues would not appear. But
1. who should do that?
2. it would bloat the OS a lot, and I would not want to carry that bloat along. This means: the additional pseudo-AI that makes basic installations run smoothly, will soon get between your legs and make you stumble when you try to implement and integrate more elaborate things.
This is crap. Pulling engineering decisions into the scope of social-sciences and then interpreting them from there is a guarantee for horrible technical quality.