The big difference is that LXD can run, in an unprivileged fashion, a systemd based distro without issue, and with a sensible view of /proc.
Docker can't currently do that, largely because running a distro in a container isn't an important goal for them.
Docker can run systemd in unprivileged container: https://github.com/vlisivka/docker-centos7-systemd-unpriv
PS.
Try it:
docker run -dt --stop-signal=$(kill -l RTMIN+3) -v /sys/fs/cgroup:/sys/fs/cgroup:ro --name centos7_systemd vlisivka/docker-centos7-systemd-unprivMy impression is that someone created a specific dockerfile to get around the issues. I'm noting that LXD can run, for example, stock debian.
This appears to be a fairly complex subject. See https://news.ycombinator.com/item?id=11216950 and the original LWN article that it depends from.
There are quite a few issues with running a systemd-based distro in a container. The first being that /sys and /proc are basically not namespaced. So if you're not careful, systemd might start modifying your host. There's some work to improve this (the cgroup namespace -- yes, that's a thing now) but the point remains that allowing a root process to start touching /proc and /sys inside a container won't end well. I believe that LXD tries to get around this problem by mounting a FUSE filesystem on /proc and /sys that does a bunch of fakery. I don't like that, to be honest. It should be the kernel's job to namespace things properly.
You can have as many processes as you like running inside a Docker container, you just a need a single process to "boot" them, even if it's a simple shell script.