Why is it bad to map network drives in Windows?
I imagine the strongest reason for not mapping network drives is that the admins don't want to deal with the headaches of maintaining an index of a finite number of drive letters in addition to the network paths. For one, there might be too many commonly-used network shares to assign drive letters to all of them, and in a large organization, not everyone will have access to all the same shares. Share names are also more descriptive and potentially less ambiguous than drive letters (more on the ambiguity later).
Second, you can run into drive letter collisions. If someone's PC has a memory card reader, that might gobble up four or more drive letters. A and B are typically reserved for the floppy drives of last century, and C and D are usually reserved for the hard drive and optical drive, so the card reader will use E, F, G, and H. If one of your network drives is usually mapped to H: via a logon script, this poor person either won't be able to use the card reader's H: drive or won't be able to mount the network drive.
Unless someone within the organization is responsible for allocating drive letters for specific purposes, the network drives could also end up causing a lot of confusion. For example, suppose you map drive S: to the share that has the setup programs for all your site-licensed software, and someone else maps S: to the shared drive where they drop all kinds of shared documents. When you try to explain how to install some software, you tell them to open their S: drive and find the setup program for Microsoft Office, but all they can find is a folder named office, which contains a bunch of miscellaneous files someone dropped there for a temporary file transfer. It might take you 5 or 10 minutes to sort out the confusion.
There are also some potential performance issues if a server goes down or if a machine is taken off the network. For example, if you map network drives on a machine, then remove the machine from the network (maybe it's a laptop), the machine may appear to hang upon logon while Windows tries in vain to mount the missing network drives.
On the other hand, on older versions of Windows, I've noticed that file transfers to or from a mapped network drive often go much faster than if you browsed to the network folder and performed the same file transfer--in which case, most people would prefer to map network drives.
The simple answer is that it isn't a bad thing. Network drives are perfectly safe to map as drives.
The superstition comes from the fact that you shouldn't be mapping foreign (i.e. Internet) drives as local because files opened from mapped drives are opened using the "local" zone, which generally affords them less protection - and if the files are actually coming from the Internet this is a reduction in security.
If, as I suspect is the case, you're actually mapping intranet network drives, then opening the folders as mapped drives is exactly as secure as accessing them via their network path names. The only difference is that having them mapped is more convenient.
In my experience, it mostly centers around badly written software.
If person A works on a suite of files that are mapped to G:, and then person B tries to open the same set of files with the same path mapped to H:, things fail.
If you use UNC paths, then assuming that person A and person B's computers can both see the share point, everything will work fine.
Sure, the ideal solution is to use software that doesn't store file relationships using absolute paths, but that's not something you can always control.
A lot of software in the CAD/CAM markets is poorly written, and barely works at all. Since the market is rather small, there is little competitive pressure. I know at least one piece of software that has had issues with absolute paths for the last 5 major releases, and they still remain unfixed, despite reporting the problems to the company.