Oh, true, but often you need to structure your code style and standards around things other than a cadre of expert programmers and 1337 hax0rz. Larger organizations often have a more middle-of-the-road average programmer, and prefer the standards to be set such that the code is generally understandable by those folks, as they're the ones who will end up doing maintenance on this code 10 or 20 years from now.

With long-lived or institutional code there's often more than just "does it look like it runs" involved. There can be detailed code reviews, correctness proofs, requirements for defensive coding, and other things thrown into the mix that complicate things.

For example, if there's a general requirement for defensive programming, type checking, and suchlike things, having B&D features in the language will, if they're properly defined, reduce the number of lines of code over the alternative. It's much more concise to throw types on the declared parameters of a sub or method than it is to have code in your methods that do the typechecking for you, and it's generally less error-prone project-wide as there's less code that you have to write.