Facebook was a large contributor to Mercurial for a number of years [0]. They wanted to contribute to making Mercurial scale but it seems like they wanted to move faster and/or in a different direction than the Mercurial team wanted. Funnily I think they originally chose Mercurial for essentially hitting those same roadblocks from the Git community. Instead of continuing to contribute to Mercurial they forked and continued working on it internally, now released as Sapling.
Many companies/organizations won't hit the size/scale where this matters but there are certainly plenty of companies who have large repositories and contributors that would benefit from something like Sapling over Git/Mercurial. These tools start to become slow. Many addons have been created to ease the problem (LFS or Microsoft's VFSforGit, narrow/shallow checkouts, etc.) but they also add complications (LFS especially in my experience). Monorepos have their advantages [1], and even with disadvantages they exist and won't go away. It's more appealing to migrate a monorepo to a new tool that adds more benefits specific to monorepos than to break apart a monorepo into separate repos.
The architecture that's being moved into seems to be less decentralized which is what Git/Mercurial were initially pioneering. I believe Google has essentially also built their own server-side SCM [2] and made Git/Mercurial clients (or wrappers for a client). I believe Microsoft did something similar forking Git and/or making their own server-side SCM but I don't recall where I came across that.
Many companies/organizations won't hit the size/scale where this matters but there are certainly plenty of companies who have large repositories and contributors that would benefit from something like Sapling over Git/Mercurial. These tools start to become slow. Many addons have been created to ease the problem (LFS or Microsoft's VFSforGit, narrow/shallow checkouts, etc.) but they also add complications (LFS especially in my experience). Monorepos have their advantages [1], and even with disadvantages they exist and won't go away. It's more appealing to migrate a monorepo to a new tool that adds more benefits specific to monorepos than to break apart a monorepo into separate repos.
The architecture that's being moved into seems to be less decentralized which is what Git/Mercurial were initially pioneering. I believe Google has essentially also built their own server-side SCM [2] and made Git/Mercurial clients (or wrappers for a client). I believe Microsoft did something similar forking Git and/or making their own server-side SCM but I don't recall where I came across that.
[0] https://engineering.fb.com/2014/01/07/core-data/scaling-merc...
[1] https://trunkbaseddevelopment.com/monorepos/
[2] https://www.quora.com/Why-do-Google-employees-use-Piper-inst...