I agree that containers are not the right answer for everything...and certainly not even for most things. But it is the quick way to get someone up and running in a repeatable manner without having to go through the pain of building an older version of gcc. It also saves the end user (read: not an expert that does this kind of thing all the time) to share in the excitement when our new game runs for the first time on the hardware we just built.
A better solution would be for someone to patch the makeinfo scripts in both gcc and in binutils. I haven't gotten around to doing that yet, and with my own load I don't think I will for a while. I'd love to be able to port these changes to a later version of the toolchain, but that requires adding even more work as we are basically maintaining our own target at that point.
If you have your own cross-compiler build, you probably also have your own set of libraries that you use for your tasks too. These are all external to your compiler tree. That's the same concept used for the container -- you simply mount your source volume and compile. The container doesn't have any other libraries in it as it doesn't need them to compile code -- your code provides the linkage.
Just my two cents.