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.