Hello and welcome here, Max66.
Lots of questions in a single post, I'll try to addess them all. 
The image consists of two parts, the linux operating system, and the Enigma application.
The Enigma application is the same for all boxes, so from a user experience point of view there is no difference.
For every box, the manufacturer supplies the kernel drivers to provide dvbapi compatibility. These drivers are in binary format, and compiled for a specific kernel version. Drivers are written under NDA from the dvb chip manufacturer, no source is available. So the manufacturer dictates which Linux kernel we can use on any given box. Some regularly update them, some are stuck in the past and haven't been updated in ages. These differences come to light when you need OS support, for example for USB devices, for which newer = better.
The difference between OpenPLi 3 and 4 is purely a technical one, related to the build process. The Enigma part of both is the same, so from a users point of view there is no difference. We only maintain the latest version for a box, so you will see changes in 4 that are not implemented for 3. The tweets are always based on the current git development branch. Documenting everything for every box is a daunting task, for which we unfortunately don't have the manpower.
An OpenPLi image runs on our own version (distro) of the OpenEmbedded Linux OS. It can not be compared with other (non-OpenPLi-based) images, where you sometimes see references like OE1.6 or OE2.0. Our Enigma is a fork of the original version, as released to open source by Dream Multimedia many years ago. Since then, we maintain our own version, in contrast to a lot of other images, that simply run a copy of DMM's image, with a new skin and some additional plugins.
The dependency you describe is mainly linked to drivers. As said before, those are supplied in binary format, and define the interface between Enigma and the hardware. The specs of the chipset are a closed guarded secret, and supplied to the manufacturer under NDA. So writing our own drivers would be extremely difficult, and require a lot of reverse engineering. If you maintain an image for lots of different manufacturers, standardization is very important. If everyone makes their own decisions, you'll end up with code littered with "IF #thisbox THEN dosomethingspecial", which if you have to maintain 20+ types will quickly become a mess and unmanageble. So we try to stay in contact with the manufacturers to try to make the interface as standard as possible.
In the past, this was never a problem with DMM. But since the market has been flooded with competitors, and DMM as a result tried to get them of the market by changing their license to a closed source one, all contact has dried up. As a result, our and their version drifted further and further apart, which made it increasingly difficult for us to support them without lots of exceptions in the code. An other issue is the kernel, that, as you noticed, it stuck in the past, leading to all sorts of issues.
Because of all this, and the fact that users will come here asking for support, has led to the descision to drop the support. We simply don't have the manpower, nor the time, to provide that anymore.
