I'm one of the two devs which bootstrapped PVE on 64 bit ARM, so maybe I can give also some insights here.
At the time it was not straight forward - mainly for the kernels build config, which is a bit hard to get right even now and was worse then.
I'm currently not full on working with it but we use a MP30-AR0 board with an APM X-Gene 1 SoC (8x2.4 Ghz, KVM support, ARMv8) which I periodically update.
One possible nice looking SoC would be the Cavium ThunderX (each 48 cores @ 2.5 GHz, also ARMv8), see
https://system76.com/servers/starling
Also
https://packet.net already offer them, AFAIK.
Main technical problems are currently the Kernel, it needs some effort to bring one out which supports a lot of SoCs and boards, as a lot of development effort happens in the ARM space this got easier already, especially also with the adoption of PCI(e) as root bus and EFI as firmware (not that UBoot is bad, just EFI is more common and "server people" are used to it).
The second problem is the KVM/QEMU management stack (qemu-server) as we need quite different things form ARM as for amd64, but work toward making this a lot easier is under way.
But no date for an test release known, for Toms and mine reasons stated above.
I know this is a Proxmox forum, but I think these types of IOT boards are more suited to Docker Swarm and/or Kubernetes than a full-function KVM/LXC management framework.
I mean, not to say that a cluster of such smaller hardware wouldn't be great for those orchestration tools also LXC, you could surely do nice things with them!
Just LXC is really lightweight (in fact it was the technology used by Docker for a long time, and it wasn't abandoned because it was bad but as they needed other things too and windows support, AFAIK) and if you simple not need the complexity of the orchestration tools and just want to run a few services here and there with the comfort of our HA stack it would be a nice fit too, in my experience.
For KVM i totally agree with you here, on such small devices (in comparison to server hardware) it may seldom make sense to run a full VM there for production use.
Of course they could do really well as a simple, low-cost/low-power quorum node for a 2-node cluster.
If you plan this go in the direction of QDevices, you have to do much less (need no multicast, not running instance of your cluster filesystem).
With a Debian Stretch on ARM you should be quite ready to go (corosync-qnetd) would be the package. I hope than I can pick up again my series integrating this in PVE soon, until then one must manually set this up.