What you are describing sounds horribly bloated for many microcontrollers, although, something like that may work on some of the larger 32-bit devices. There is a common misconception that adding many abstraction layers etc. keeps development time down by sacrificing performance, but in reality, it's usually also a huge waste of development time.
In real world, MCU applications often are a few thousands of lines of C code, and the "abstraction layer" for peripheral devices such as ADC, I2C, etc., is typically one or two functions of a dozen line max.
If this is not the case, it should be first investigated whether you are doing something horribly wrong, before jumping into over-abstraction or "frameworking".
Also, in the microcontoller world, it's usually better to accept that you are writing your code for one particular device. Although, when you design your modules (C files) and functions right, most of the code can be reused if migrating to another device.
You should really use C (not C++) for most microcontroller work and forget about object-orientation. One may argue that C++ has its uses, but definitely not in the microcontroller world, at least in general sense. Using C++ for MCU development is really forcing round peg in square hole. They are fundamentally different. I know there will be people who will disagree loudly, but it's their right to be wrong. Really, you should try to understand what you are doing on a very fundamental level. PC software world stopped being easy in early 90's, but it's understandable, because it's a general-purpose environment; just don't try to force that development model or those software ideas on embedded systems.
Many microcontroller applications do not even use dynamic memory management at all, in any form. In most microcontroller projects, it's super important to keep the state space as small and predictable as possible. You are running your particular application, and it will never run out of memory or have errors opening devices, because the memory is statically allocated for the job and the devices are always provided by the MCU and there is no driver to fail.
It depends heavily on the complexity of the projects and microcontrollers being used; some larger projects that utilize large 32-bit MCUs may start benefitting from the more complex software architecture, in which case an operating system may be a good idea; but this is the special case, and you need to really know what you are doing, and do a proper analysis on the reasons for that kind of general-purpose approach.
But in many many cases, minimum no-bullshit no-"framework" C "bare metal" is the only sane and feasible development model for microcontrollers.
So, there is no general answer. It really depends. But seeing your background, I really suggest you start by doing some simplistic bare-metal C projects; it will be the basic lesson you simply cannot live without even if some of your projects ended up using operating system, device drivers and OOP.
[PC] software development and computer science stuff are totally and utterly irrelevant skillsets when designing for microcontrollers. Forget it completely and start from scratch. It's sad that microcontroller development is not really taught properly anywhere AFAIK. Don't mix that up with modern computer thing; it's very different, in a very fundamental way!