It also has weird bouts of high CPU usage, even if running containers are not busy. I think it's due to overhead with osxfs handling local disk changes (e.g. you've mounted a volume with a large git repo, and in that repo on the host you switched to a much different revision). It's hard to troubleshoot because it's not obvious how to get into the VM to see what's going on.
FWIW, https://stackoverflow.com/a/68561693/3230028 is how you do that.
Overall, this is an issue that I think goes beyond Docker on a Mac. We have multiple examples of development targeting one platform, or involving tools native to that platform. But because of preference, or conflict with other tools, or policy, we end up with these emulation or compatibility layers like HyperKit/Docker for Mac, or WSL/WSL2, or WINE, or frankly WebAssembly/Emscripten/whatever. And I think the result is almost always worse than if people just found the most native set of tooling for their primary use case and used that.
What is it about macOS that makes Docker Desktop for Mac worth it, if your development workflow is heavily container-based? At my workplace, it's mostly policy and preference issues making Linux unsuitable for the majority of the user base, even though that majority is working with containers constantly and targeting Linux.
I guess you can pick at this and point out that we're not writing software in assembly for a reason, but I feel like there's a line where you have too much abstraction, adaptation, or emulation, and for me workflows built around something like Docker Desktop for Mac just so we can use macOS are over that line.