Way back in the day we did some due diligence on our source control - at that time CVS - and settled on darcs as the most elegant.
Around the same time Linus created git and the rest is history and eventually darcs went the way of betamax.
Darcs was never good enough, not even close. It wasn't even good. It fundamentally failed at the most basic thing required of version control, that you can actually use it to get work done, because it became so slow with even small codebases that you had to give up and switch to SVN. You could have a codebase with 200k lines of code and basic operations would take 30 MINUTES or longer. (not to mention that darcs would lose data, and you could get in situations where conflict resolution was impossible and you would just be stuck and forced to manually fix things outside of VC)
https://en.wikipedia.org/wiki/Darcs#Shortcomings
Darcs was and still is unusable and inferior.
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.