Surely you jest, Jim. There is only one robot with a non-real-time OS. Who in their right mind is going to suggest having multiple independent programs, (up to seven in my case so far), running on an a general purpose processor, with no guaranteed execution time frame, and no easy shared memory, who is going to think this is needed to teach young minds about robot control?
There are so many basics to learn about in robotics before even multi-tasking is needed, let alone the infinitely more complex architecture of multi-processing, so I do not fault DI for not designing for multi-processing.
Multi-processing for a $100 robot? Really not important, but by providing the interface class and API open source, “the exercise is left for the reader” to coin the frequently used educational idiom.
Since the GoPiGo3 board does not have GET_GROVE_xxx commands, a no init feature cannot actually create a fully configured, fully usable GoPiGo3 class object that knows what type of sensors and what state those sensor/effectors are currently in.
Now when we talk about one robot as the interface to multiple asynchronous sensors over multiple channels (direct to/from GoPiGo board - Digital, Analog, and processor through GoPiGo board - pigpio, I2C) - here I don’t expect anyone to be able to understand it enough to dink with it so having the GoPiGo3’s ATMEL firmware locked up tight gives me comfort that I can treat that whole thing as a black box - as long as the company is responsive to questions about it like DI/ModRobotics has been.
The fact that I am the only person, ever, getting fatal I2 [Errno 121] is evidence they made pretty good assumptions designing this bot.
So, all in all, the answer to your question - because 99.999% of the programmers will always want to, (and need to), do a full-up hardware re-init. There was no need to “design for every possible use case”