Excellent question, @TimSueberkrueb, thanks for bringing it up. Before I say anything else, note that LXD support will be returning with feature parity with multipass-- virtualization just doesn’t work everywhere.
That said, why the virtualization route in the first place? This revolves around the introduction of bases. A fundamental question we needed to answer last cycle was: how should a snap with base: core be built differently from a snap with base: core18, and differently from a snap with base: fedora (if that existed)? The answer was challenging, particularly when you consider that changing the base also needed to affect stage-packages and build-packages, along with the fact that snapcraft is a cross-platform tool (across Linux distributions is challenging enough, then throw in OSX, etc.). What should happen if you try to build a base: core18 snap when running on Fedora? Or a base: fedora snap when running on Ubuntu? Even simpler: what should happen if building a base: core18 snap on Xenial?
The only solution that seemed to cover all the requirements here was to have snapcraft use a different operating system for building depending on the base. The initial idea was to use a LXD image per base, but then we realized that specific kernel features are required in order to use build-snaps, and LXD sits on top of the host kernel (as does Docker, although Docker has other issues preventing it from running snaps, too). Thus we arrived at multipass as the only sure-fired way to make sure folks were building on an image that would definitely build snaps, and it also ensures that machine A is building snaps in the same way as machine B.