The problem comes in when you need to manage 100's of machines, and there isn't a single shell that is in everyone on the team's muscle memory.
Shells are just REPLs; use your editor to drive them. This helps document what exactly was done on a machine, and encourages code re-use (yank-put from last time) and other tidbits you get when editing (git repos, git search, etc.).
If you all log in to the same account, you'll need to pick some standard. It doesn't really matter if the system decides on that standard or if you just ask the team what they prefer and pick the most popular shell. When in doubt, install all shells, log in to sh and let people start their shell of choice.
nobody cares about user accounts. use whatever you want on your laptop, nobody cares.
however if a script reaches a production server, it should either be sh, bash, or a real programming language (python/ruby/perl/whatever).
the ugly stuff i've seen is that some snowflake user drops their scripts written in ${shell_of_the_week} and leaves, the script breaks and now i have there's this thing that has to be not only fixed, but possibly rewritten from scratch.
The "one off" script from two years ago that you really, really need right now probably won't work. Perl/bash are less likely to hit this (they stopped changing years ago). It's an open question whether golang will have this problem.
If you operate your own data centers, then you need to do configuration management of the machines, so their configurations are immutable/reproducible.
(These problems all arise once you have a large fleet and a large ops team.)
Sure, it is not the same as your home machine - but even with the right shell, you customized config files woukd still be missing. So it is easier to get used to defaukt setup on defaut shell when managing many machines.
(This is the reason I had to learn vi back in the day: sure, my machine has lovingly customized emacs.. But that old Sun one needs to debug? Vi only.)