You can easily get just part of your data using a binary tree or a hashtable and simple C functions like for, while, if. In most cases there is no need for a full-blown SQL engine.
On the other hand, microcontrollers typically have ample Flash storage for code, but very limited amounts of RAM. Instead of making everyone rewrite their own memory-efficient data structures, it might well make sense to have a single, general-purpose implementation -- even if some of the code goes unused in a particular application.
Keep in mind that the Flash storage has a limited number of writes, so keeping frequently changing data in memory and choosing a right data structure can be crucial for your data's life span. SQL is not an universal solution for all use cases.
You are not wrong, but consider that the problem may be handled a number of ways. Once I move to storing everything through IonDB, you will be able to choose key-value stores that could wear level, should one be implemented. Such algorithms have been suggested in other works. Furthermore, if the device supports a storage API that already does wear levelling, you than a SQL layer on top should not hurt.
Well, if you can really make SQL work well within such constraints and be convenient to use - I see no harm in it.