LOL...can't argue with you there.
My son is a pretty amazing programmer and he convinced me that we should use C++ to build ST_Anything many years ago. This was some of his early work. If you want to totally get lost in object oriented programming, take a look at his OmniThing code.
Be that as it may...ST_Anything really isn't as complicated as it appears.
The Arduino Sketch simply creates a Communications object that is specific to the board type that is being used. These objects are implemented via the "SmartThings..." libraries, as this whole project started on ST using the now defunct ThingShield for the Arduino UNO/MEGA boards. Once that board was no longer available, I added support for LAN connected devices using some great example SmartThings Community code from Hubitat's own @chuck.schwer!
In addition to the "SmartThings..." communications object, the sketch creates individual 'device objects' for each type of sensor or actuator you'd like to attach to the microcontroller. Each of these devices is implemented as a C++ class, inheriting reusable code from parent classes like the InterruptSensor, PolllingSensor, and Executor. These classes expose a standard interface to be used by the 'Everything' class.
Finally, all of these objects are stitched together by the 'Everything' class. It takes care of scheduling the polling sensors, calling the interrupt sensors every time through loop(), and updating the executors when data is received from Hubitat. Everything also takes care of sending status updates back to Hubitat. By using a replaceable communications object, I was able to abstract that portion of the code into the aforementioned 'SmartThings...' libraries. This means to add support for a new microcontroller, I only have to add a new 'SmartThings...' communications library. None of the other code ever needs to be changed.
This is what the C++ object oriented design brings to the table. While definitely more complex at first glance, it actually is not bloated, IMHO. You'd have to write just as much code within the sketch to do the same amount of work.
To add your VEM7700 device, I would simply start with the PS_AdafruitTSL2561_Illuminance.h and PS_AdafruitTSL2561_Illuminance.cpp files as a baseline. Then make a copy of both files, change their names to PS_AdafruitVEM7700_Illuminance.h and PS_AdafruitVEM7700_Illuminance.cpp, then modify their contents accordingly to communicate with the VEM7700 board.
I am intrigued by the VEM7700, so I ordered one from Adafruit this evening. I'll have it integrated into HubDuino within a day or two of receiving it.
I know you prefer to 'roll your own', which I completely understand. I wish you all the best on your endeavor. If you want some assistance on the groovy side, I am happy to help. Using Composite (Parent/Child) Drivers really is fairly straightforward, especially on a sensor device since communications is only one-way.