In the case of Facebook, they explain the rational is for being able to smoothly refactor code in atomic ways. It makes it manageable to impact two different parts of the project because one does not need to modify at one place then go to the other, upgrade the dependency and do the other change. Just do the change in both and commit.
For Google the rationale of the article is more around integration testing. If one developer commits code in a shared library and that breaks a depending product, then the build for this commit will fail in minutes, not a dependent build a few days later.
But at their scale it also has a big drawback: scalability. With thousands a commits a day and such a large codebase, version control software tend to slow you down too much and builds take days on developer machines. But instead of switching to chunked repositories and loose time for each and every new feature from then on, they took the hard path and scaled the environment. It cost them a lot once, but it should be a win for the long term. From what is explained in articles, Facebook focused on tweaking Mercurial (and released those tweaks, thanks!) while Google created a distributed build infrastructure running on all developer machines.
So I am quite annoyed by tooling such as Bower which assumes a 1-1 relation between projects and repositories. If you want to create a consistent set of micro tools, they are to be stored in different repositories and you have to ensure yourself that it is published consistently.
The single repository is the strategy I choose to have for my latest personal development, of course at a different scale than Facebook and Google. This is a small library with multiple modules graviting around a small core, implemented in several languages (for the moment there is only one module and two languages, but more should come if the idea works). I decided to put all of them in a single repository.
I had to fight a bit with tooling, for example Travis CI does not work very well with multiple languages, all runtimes are installed but only the first gets the specified version while others remain at the default one. So I chose to specify Java version through the standard way and manually install Node.
On the other side, it also makes it harder to get your workstation ready to develop on the library. For that I included a Vagrant configuration at the root of the repository which is able to boot a ready virtual machine on which one can compile the code (and edit it from the host). For the ones not using Vagrant, at least they can see the required software in scripts.