However, we were constantly hitting the exponential merge conflict bug. Darcs messed up our repo state several times and cost us days of productivity. It had nothing do with the size of the codebase; as far as I remember, all that was needed to trigger the bug was to make a patch that happened to include the same code line change as someone else. It felt ridiculously fragile. As far as I remember, once you hit the bug, your repo was beyond saving. You had to roll back to a backup.
We still stuck by Darcs until around 2009-2010 when it was pretty obvious the writing was on the wall and Git was going to eat the world, in large part thanks to GitHub.
If you do encounter a slow merge with darcs, the normal practice is to treat that as a mistake, step back and re-do your commits to be less conflicting - not to waste time waiting, ending up with a very slow merge in your history.
The original exponential merge corner case, and subsequent lack of a clear prevention mechanism or even clear description of the issue, has had a big anti-marketing impact, and has probably kept darcs out of the limelight ever since the departure of the original lead developer, despite a small heroic band of maintainers working on it to this day.