Um. In a way, you have a point. But, to be a devil's advocate, I'll point out that there are such things as subroutines and internal APIs. The general idea is to have any fine-tuning for a particular sensor, or even group of sensors, be placed in a subroutine that can be modified for that sensor; the API to which that sensor delivers data would then look at summary data, and so on.
The design, care, and feeding of such APIs is a science unto itself. The APIs themselves aren't necessarily fixed and, potentially, can be made flexible. In fact, that's what Object Oriented Programming is all about, where additional data to be moved about can be added to existing objects, using inheritance so one doesn't necessarily have to reprogram everything.
Having said that, my training was primarily with procedural languages like FORTRAN, BASIC, C, and more assembly languages than I want to count. And the half-dozen operating systems (albeit, for DSP work, but that's pretty slim pickings for an OS developer) that I've had to write. And, being one of those people, there's the downside of OOP code, in that things that can be done ridiculously fast in, say, C, has to spend an inordinate amount of time running around in the structures of OOP code so, well, inheritance works and all. Which doesn't do real-time code any good.
But I keep on running into the occasional article that says that OOP code can be used for real-time fun.
So, to summarize: you have a bit of a point. But I strongly suspect that things aren't as bad as all that, and the people writing the OS and code probably knew that they wanted their work to be extensible and not have to be re-written from scratch every time a bit of hardware got changed.
