Debian can rock. You just have to know what your doing and it's perfectly OK for self-deployements..
It all depends on the corporate/business culture, some companies require very good support in their products, other companies prefer to rely on their own resources completely. Most people are inbetween. And it's not like you can't get good help for Debian if you want it. There are plenty of smaller companies, consultants, and individuals that support it.
If I needed something that was suppose to be supported I'd get Redhat or possibly Novell. Depending on the requirements. Also if I depended on closed source software, such as Oracle, matlab, or whatnot I'd use Redhat becuase it's certified to work.
But if I was responsable for it myself, and had to provide support or had a limited budget then Debian would be my first choice, baring anything that may come up.
For instance one thing I've been playing around with in the past couple weeks is trying to muck around with setting up a 'Linux Domain', similar to a Active Directory setup. Should be suitable for large deployments, all the software is proven and capable. Of course this is just all experimentation for me..
I have a Kerberos realm setup (with a fake top level domain .goob.), all the users and services are athenticated to it. I have a OpenLDAP server to take care of groups and users.. It's uses TLS style encryption via OpenSSL to protect the information on it. Note that there are no passwords and no users are authenticated against the LDAP, all this stuff is stored in Kerberos database (although I did test libpam_ldap and it worked, once I added a password entry in the ldap database). Even access to the ldap information itself is authenticated using SASL thru GSSAPI. Normal services like GDM and login use libpam_krb5. Kerberized services like OpenSSH and OpenAFS are setup not to use pam, but can communicate to kerberos automaticly.
I use OpenAFS for my home folders, which is pretty cool. OpenAFS seems to me to rock and is under healthy and active developement. It's very fast, the volumes allow for easy replication and backup. Local file cache keeps it fast, and every time you access a file, even in cache, it checks back to the server for updated versions.
All of this is aviable thru Debian's normal apt-get resources and is maintained. It's pretty snazzy, IMO.
Also with Debian's OpenAFS version I found something funny. It has a list of a whole crapload of AFS servers on the internet. 158 actually.. I think. Mostly read-only.
It's kinda cool to go snooping around other people's servers...
for just *.edu afs servers:
drag@spock:/$ ls -d /afs/*.edu
/afs/acm.uiuc.edu /afs/dev.mit.edu /afs/northstar.dartmouth.edu
/afs/andrew.cmu.edu /afs/ece.cmu.edu /afs/physics.unc.edu
/afs/asu.edu /afs/eecs.harvard.edu /afs/physics.wisc.edu
/afs/athena.mit.edu /afs/eng.utah.edu /afs/pitt.edu
/afs/atlas.umich.edu /afs/engr.wisc.edu /afs/psc.edu
/afs/cats.ucsc.edu /afs/glue.umd.edu /afs/qatar.cmu.edu
/afs/cede.psu.edu /afs/hep.caltech.edu /afs/rose-hulman.edu
/afs/chem.cmu.edu /afs/hep.sc.edu /afs/rpi.edu
/afs/citi.umich.edu /afs/hep.wisc.edu /afs/sbp.ri.cmu.edu
/afs/clarkson.edu /afs/iastate.edu /afs/scoobydoo.psc.edu
/afs/club.cc.cmu.edu /afs/ir.stanford.edu /afs/scotch.ece.cmu.edu
/afs/cs.cmu.edu /afs/lsa.umich.edu /afs/sipb.mit.edu
/afs/cs.pitt.edu /afs/math.lsa.umich.edu /afs/slac.stanford.edu
/afs/cs.rose-hulman.edu /afs/msc.cornell.edu /afs/umbc.edu
/afs/cs.stanford.edu /afs/msu.edu /afs/umich.edu
/afs/cs.uwm.edu /afs/ncsa.uiuc.edu /afs/umr.edu
/afs/cs.wisc.edu /afs/nd.edu /afs/uncc.edu
/afs/dbic.dartmouth.edu /afs/net.mit.edu /afs/wam.umd.edu
Kinda interesting. All of it uses normal Unix file symantics like it's local.