We use it a bit, mainly as a side-effect of infrastructure. For instance, our CI runs each job in a container; the spec for the container is checked into source control. That way its easy to add new software in CI, just change the Dockerfile in the project repo. Also easy to run CI jobs locally for debugging.
Then some of our integration tests themselves use Docker, for various things. And at that point, docker in docker comes in handy.
We just run regular docker-in-docker though, which is indeed a very leaky abstraction, lots of pitfalls.
A use case that we often get asked about for Docker-in-Docker is using the outer container as a dev environment that includes a developer's tools, ssh, and a dedicated Docker (CLI + daemon). It gives sys-admins a lighter-weight alternative to VMs for launching those dev environments, and works well in scenarios where efficiency & cost reduction is important and having VM-level isolation is not required. The problem is that prior to Sysbox, those outer containers had to be privileged containers, which provide very weak isolation (e.g., it's possible to turn off the host from within the privileged container!). With Sysbox, those outer containers are now properly isolated via the Linux user-namespace, truly enabling this use-case.
Then some of our integration tests themselves use Docker, for various things. And at that point, docker in docker comes in handy.
We just run regular docker-in-docker though, which is indeed a very leaky abstraction, lots of pitfalls.