I’ll start by saying thank you for your continued contributions to the snap ecosystem and reasoned responses here and throughout the forum. 
This is inaccurate. We actively choose established technologies for all the pieces, but some of those technologies necessarily need to be sufficiently new to support full strict mode and other requirements (this is the nature of software development of course).
AppArmor has been upstream for many, many years and while there were some out of tree patches for a period of time, there was a heavy lift to upstream them and they were all were accepted. As outlined in my previous response, there is only one piece missing from the upstream kernel: AF_UNIX mediation support. Upstreaming that has not stopped, but has been complicated by its intersection with LSM stacking, which is also important because when fully realized in the upstream kernel will allow strict mode snaps everywhere, including enforcing SELinux systems.
Flatpak and snaps obviously have some overlap but have different goals.
I won’t presume to speak for flatpak, but I very carefully framed my response to talk about snap’s goals wrt containerized applications and how they “integrate comfortably into the system”, are “isolated from each other and the system”, how “snaps [can] interact with the host and each other in controlled ways” and that “the sandboxing model is abstracted away for users and developers”. Another goal I didn’t mention above is that in general snaps are able to use all of Linux rather then having to be rewritten to use particular APIs (though, as seen with all kinds of work by various developers in a healthy cross-distro and cross-project effort, snapd does not preclude the use of useful new APIs, like portals). Some of these older APIs necessarily need wider permissions since they weren’t designed with confinement in mind (eg, x11 or raw-usb), but we are able to enable these applications through interfaces or classic snaps.
In all, the sandboxing technologies chosen for snaps work in concert to achieve all of these goals in the immediate term for distros that do a small bit of enablement (eg, Manjaro did it in a couple days at a snapcraft summit) or who are derivatives of distros that have done this enablement. The technologies were also chosen since in the medium term they will allow any non-enforcing SELinux system to “become enabled” naturally by simply upgrading their kernels and userspaces (ie, distros would get strict enablement essentially for free when moving to a new kernel and refreshing their distro’s package versions; admittedly, this effort has taken longer than anticipated or desired, but is close to being realized). There is also a longer term effort for the sandbox to work on enforcing SELinux systems via LSM stacking.
We can’t get there in one step, but we can allow everyone to enjoy snaps on this journey so we allow snaps to be installed on systems that don’t support strict confinement. This means important software that might not otherwise be available to all distributions is available to everyone (ie, Spotify need only target ‘snap’ rather than the myriad of distributions out there with their native package formats). In terms of security, allowing snaps on systems that don’t support full strict mode is in and of itself an improvement for everyone because people aren’t cutting and pasting random ‘curl piped into bash’ instructions, enabling random PPAs/package repositories that might introduce system instabilities, etc. Instead, users can download and install snaps in a secured and verified fashion.
This is overstated and a bit misstated. Sure, snapd powers Ubuntu Core and works well on Ubuntu and its many forks and derivatives but there are distributions who have full AppArmor support because they chose to enable it. Manjaro and Solus are two distributions that are quite different from Ubuntu (they aren’t Debian or Ubuntu derivatives) and have chosen to do just that and snapd and AppArmor developers are always thrilled to assist any distribution enable strict mode. The lift that I mentioned above and the continued work on LSM stacking are precisely to bring strict mode snaps to all the distros and it is the current status that requires distros to enable strict mode. LSM stacking is a multi-LSM, multi-distro, multi-company, multi-developer effort (ie, it is desirable to a lot of people besides just snap users) where we continue to give significant resources so we may improve the snap experience for SELinux systems.
The way I like to think of snaps (and why I’m happy to work in the snap ecosystem every day) is that snaps aim to be a delight for users and developers, are widely available and improve application security for everyone. This is a lofty goal and there is still work to be done, but we’ll get there.