Well, he laid out why pretty clearly, it is because -
And that is correct about 'nix, as opposed to release .x of Windows or Mac (generally speaking). If I remember correctly, there were also compiler incompatibilities old to new.If we move up one version of Debian, chances are the built executables will no longer run on other distributions of a similar age to Debian 8 which are still supported (and will continue to be for several years to come).
The problem is that the Linux community as a whole 'does not do binary compatibility' - but we have to, which means we have to build on what some might call 'legacy distributions'... I say some, because things like CentOS/RHEL have a support window spanning 10 years - precisely because upgrading Linux is a great deal of work when it isn't just your personal machine!
A container allows you to locate the .dll's and such needed for your app specifically to locations for your app, regardless of what the system is running, which tends to cut down on the problem of dll hell. Building in a VM would turn out an executable, but that wouldn't contain the dll's needed for the build type to be installed, or would try to force those into the general system places for them, which would probably result in "you have held broken packages" messages.
I probably said that poorly, but the end result is that a container is self contained, much as the name implies, and so allows you to distribute much as he says.
The above is my take on it, of course, I *could* be completely off too.
Yes, just as programs written for DOS or Win. 3.1 could run on Win 95 and up or Mac OS(7,8,9) could run on OSX, but they sure were not supported for that, they were supported for the platforms they were designed to run on. As an example, I can comfortably run almost any Windows version of Lc on 'nix through WINE, but if I found a problem doing that, I for sure wouldn't expect LiveCode to provide support for it