Eh, yes it is. Apple doesn't provide a containerisation API for their OS, which means Docker is forced to run non-natively!
Containers on macOS don't use OCI images or anything like that, but scoped and grouped access to system resources with a separate user land that 'looks' like a full OS has been available for over 5 years. Even without that, XNU has plenty of facilities for it, and even if it didn't you'd still be able to use Launchd environments (which are more akin to LXC).
Docker relies on specific implementation details of the Linux kernel. It always has. That is why you always need a Linux OS somewhere to run the containers.
Example: there are artefacts you can store as OCI images that contain Mach-O binaries, and Windows and Linux won't really run those. You can even still PPC code in those binaries, and link to Cocoa frameworks. This means that the OS and architecture you are targeting will not be Windows or Linux, and that is not their fault.
Will macOS run them? That seems to be the missing functionality.
Is that true? Plenty of people are using multi-arch images (x86 and aarch64) which are essentially the Docker image equivalent of a fat binary. I might be wrong, but I think what I want are preconfigured macOS binaries packaged up a convenient image format with a layered filesystem, networking support, etc. Ideally with an equivalent linux image such that I can later switch the OS specifier and get an image containing an equivalent linux binary to run on linux.
I am for example quite happy to run a macOS native version of Postgres. But that doesn't give me the easy disposable database for testing that a docker-compose setup gives me. If I could specify that I want the "postgres" docker image in my docker-compose file, and running that file on macOS ran a macOS version of postgres in a macOS-native container then I'd be very happy.
Packaging (including fat binaries but also byte code self-unpackers) has tried to make this possible for decades but it just won't stick. Take Debian or RedHat packages for example, there have been tools and repositories for very long times that were meant to make a universal method of distributing pre-packaged (and natively also chrootable/jailable) software for a multitude of architectures and operating systems possible, but package authors just didn't really want to do the work for what is essentially not something they wanted themselves.
Building software for 1 or 2 major release versions within a single operating system is hard enough, tacking on extra systems is usually a step too far.
The closest we got (and it still exists) is autotools, but that's just build tooling. It does however make it possible to build software from a single source for many targets and check for all the required features ahead of time. But this is so close to developing the software itself that it's not really compatible with the influx of end-user-style developers that expect pre-packaged 'commercial grade' software, which is essentially what Docker and OCI and Containers are.
The only 'new' thing so far has been cgroupsv2, the v1 version and everything else (distribution, sandboxing, capabilities, separate user land etc) has been done for over three decades. But again, using it means knowing how to use chroot, cap, tun and jail for example, and not everyone wants to learn that much. So we get things like docker, which under the hood does exactly that, plus some union filesystem magic to make it cheaper/faster for registries to store data; essentially a re-implementation of dynamic linking and shared libraries, but for files.
So now we have created an interface (docker) that is easy to adopt, easy to promote and easy to use, but it's hard-wired into Linux (the kernel) and only much later (post-OCI) got some hacked up windows version that is completely different and doesn't work anywhere else (because, well duh, not-windows isn't going to run windows apps). Aside from the fact that it's an OCI artefact, windows containers have very little to do with docker containers as we know them.
Most of this stuff also didn't really come from a need to get containers on windows (or macOS) but from the need to get more 'developer light edition' into the workforce, which can be trained and onboarded faster. If you can get people to ignore the foundation they stand on, they can be put to work in building upwards much sooner. This does of course come to bite everyone in the ass at some point, because if you're standing on top some 'magic' infrastructure and something breaks, it's going to be really hard to fix it. Right now we're all trying to make it redundant enough so we can ignore the breakage, but I doubt this is a winnable race.
Docker is a convenience, not a technical solution to a technical problem.
With that said if you're doing mostly backend stuff in Go/Python/Ruby etc it's quite good. Most of my complaints are from full-stack development.
The other upside of being fully containerized - even for FE stuff - is that you side-step having to worry about having any sort of "local" dev environment configured beyond Docker/Podman/etc and some environment variables set. It makes onboarding new developers a breeze and eliminates "Weird, works locally on my machine!" types of issues.
Lots to do to combat this, like: not sharing the volume with the host (vscode dev containers recommends this)