Okay, a little bit oftopic. I will try to keep it short.

It's okay as a secondary sort item. It's also okay when there is never a scenario when you need to insert data between 2 others. At example import during a sync data from a other source. Like a stack of cards in a poker game. This will fail if you use ID's as the one and only sort item (like the SMS application does). Your Data is viewed in a order you have never thought about during the desing.
A ID in a recordset is per definition a unique identifier. This is the reason it exists. It's indexed by default. If you have only data fields with a fixed lenth the engine can find it very fast if you "Select Text From Table Where ID = 6;".
In many scenarios more than a single programm or task is accessing a database. The same happens at the N900.

Lets keep the SMS storage as example. I don't really know how it works internally. I guess how it works simply by my own knowledge and because of that what I can see as a user from outside. My example is very simplified:

You have the Conversations application, the SMS Messages are sort by ID instead of receiving time. You begin to write a SMS, close the programm and your text is stored as draft in the database. The Conversation has only to store the ID somewhere to know it is draft and the next time you will open the application it has to show up your unsent draft. Lets take the number "521" as ID for this message.
Now you start a sync with a other application, import old messages. To show it in the correct order (receiving time) you have to reorder the ID's and insert several Numbers before the number 521. You have to twist the engine only because your view does someting strange. In the most databases this is not trivial. Its not designated to change a ID of a recordset. Its forbidden. You have to make a copy of the table with new IDs, delete the original and rename the new Table.
Now the user opens the Conversation application. This program doesn't know anything about the reconstruction. It only knows "continue with Message 521" - in the best case it will open the wrong message... but it can also end in a crash because there is suddenly a receiving date of a unsend message, or a sending date in a draft. It can end up in a loop or in many rendering bugs and a broken layout because there are many messages after the draft shown. Many things and bugs can happend the programmer has never thought about. And actually he has not to care. HIS part of the programm worked just fine. He have not broken the rules.

A SMS storage database is not soooo important... but try to imagine what could happen when you build such a scenarion with a coustomer database and a billing system. Not with the reason to assign new IDs because of sorting... imagine it because you misuse the ID as a customer number. And now your management assimilate a competitor and you have to merge the customer database. (leave the country as fast as you can)

Conclusion: Never change a ID and never built a scenario it could requires to change a ID some day in the future. The maemo programmer are aware of this. Because of this there is also a warning at the Bug report #7512. When you do something like this, reboot the device immediately!

But the Bugfix is still not on scedule despite it's very easy to do: Order by receiving date or "storage_time" instead of the ID. And to compensate the application slowdown index the "storage_time". It's simple to change a "storage_time" by a other application to fix the ordering and get it how it should be. Its a datafield like many else. But changing a ID is a reason to sell your degree on ebay.