(moving/expanding from the comments)
I've always seen stuff being included explicitly from those locations, e.g. <bits/c++config.h>, <ext/bitmap_allocator.h>, <tr1/cmath> and the like, never adding one of those directories directly to the include search path. Notice that, as far as I always understood, the bits directory should be mostly left alone, as it contains implementation-version specific stuff (not necessarily stable API-wise). I cannot find explicit documentation of this, but the general structure of the library (with standard public headers in the root that include their bits counterparts) seems to suggest so.
Should these be avoided as a best practice? Or, what are the scenarios they should be utilized?
Excluding bits, the others can all be used, as long as you are willing to accept that you are depending from libstdc++ and not standard C++ alone, as specified in the documentation at http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_headers.html:
The "less nonstandard" stuff is what you find in tr1; it comes from the C++ TR1 which, is not a "real" standard, but recommendations for stuff to be included in the then-upcoming C++11 standard; before 2011 you could use it and expect some grade of interoperability with other compilers, today you can safely ignore it and just use C++11 (which is actually standardized and differs quite a bit in some details).
All ext are libstdc++ extensions, some are stuff that comes from the SGI STL, some are newer developments; it's not impossible that some of them will be included in some standard C++ proposal, but in that case they'll probably move somewhere else.
The parallel directory contains parallel implementations of some of the classic STL algorithms (details here); again, IIRC there is a proposal to standardize them, but as above I expect them to move somewhere else in case they are standardized, since rarely the standardization leaves proposals intact, and they'll need a way to let old programs run fine with the old headers/semantics.
experimental contains stuff for the new experimental Technical Specifications (the concept is similar to TR1), that should graduate to the "real" standard library when the new standards will be released; at the moment in my gcc 4.9.2 installation I can only find string_view and optional in there, but some other stuff should come; personally, as with tr1, I would wait for the tide to settle in the new standard before employing these headers in production code, because, as they are, they are both still something of a moving target, and the code quality is not on the par with the rest of the library (it's still experimental stuff, as the name says).
The ssp folder contains Stack Smashing Protector stuff. From OSDev, (Link):
Compilers such as GCC enables this feature if requested through compiler options, or if the compiler supplier enabled it by default. It is worth considering enabling it by default if your operating system is security conscious and you provide support.
<bits/c++config.h>,<ext/bitmap_allocator.h>,<tr1/cmath>and the like, never adding one of those directories directly to the include search path. Notice that, as far as I always understood, thebitsdirectory should be mostly left alone, as it contains implementation-version specific stuff (not necessarily stable API-wise). – Matteo Italiabitsshould be left alone; the others can all be used, as long as you are willing to accept that you are depending fromlibstdc++and not standard C++ alone (an exception should be made fortr1, which should be standard, and some other stuff; for details, see gcc.gnu.org/onlinedocs/libstdc++/manual/using_headers.html ). – Matteo Italia