I agree with the spirit of the idea; but I'd argue that if you can trust a generic script, written with the idea that it could be an aid to nontechical users, to harden something, that something should have shipped hardened in those ways to begin with.
Obviously, more application-specific, or lots-of-dangerous-knobs-and-buttons scripts can (and are, admins generally know and embrace the virtues of applied laziness, as well as avoiding human error in repetitive tasks) be used to harden things that can safely be hardened under certain circumstances, but not others, or apply other optional-but-might-break X, Y, and Z use cases type modifications in situations where the person using them is expected to have nontrivial site or applicaiton specific knowledge.
That's the tricky bit: much of the 'hardening' in the world occurs either because the vendor is incompetent/mendacious/no longer in business, or because somebody who has no need of a given, potentially risky, feature is turning it off. Neither situation is wholly tractable, the former because you are specifically not trusting the entity most plausibly responsible for providing hardening advice and tools, the second because it can't easily be handled in a generic way without assuming some knowledge by the user.
Now, if you are stuck in a situation where something is going out into the world broken, automated fixing is probably your best bet, but it's a somewhat perverse situation where an entity competent to fix automatically exists; but broken stuff is still being unleashed on the world.