It can get uglier than this -- third-party libraries, external utilities and other tools which are used daily for programming but which introduce non-programming-related issues in the process, such as deciding whether to use the vendor-provided packaged but sightly out of date version, or the compile-and-install yourself one, can easily add to a lot of variables that newbie programmers should not be burdened with. Issues like messing up /etc/ld.so.config so that your dynamic linker can find your just-recently-installed library, or messing with command line arguments in makefiles because they cannot install libraries and header files in the standard system locations -- this is the point where things start to look very blurry to students, and they just struggle to get their code running, most of the times making random changes to their setups which they read somewhere they found by googling on error messages.
Yes, most of this can be solved by having a competent system administrator that installs and tests every required library and external utility in standard locations, and makes sure every student system is setup the exact same way. But if you're not doing it properly, you end up supporting not only your students' programming troubles, you will also need to be able to debug their entire programming environments, which is not really the point.
That said, I do know that Python and Java can do a lot without external libraries, and thus the possibility of the previously described scenario develop is relatively minor. But that does not mean that your classes should be taught without any attention for these 'minor' details, because things might evolve in a different direction that what was originally intended during the course.
