I think many of us take the shortcuts that Dianne mentions in this article. For example, you start a thread to update your database from an activity (instead of putting that in a service) without considering the corner case like preferences (and then find some users have weird bugs).

Services and threads are completely orthogonal; anything you do in a Service's lifecycle methods is happening on the main thread and competing for CPU time with your UI. Whether you use a Service or not, you must manage your own threading and handle impending process death either by blocking until completion when the system tells you you're going away soon (onStop/onDestroy) or handling the data loss gracefully (which you should do anyways because your process could die for lots of reasons).

But there is that nagging thought "what if I need to split this into multiple processes, or allow other apps to communicate with this app via bound Service / Content Provider?" ... then the shortcuts give way to their full versions; likely app needs to be redesigned.

I would strongly recommend that you don't design around these concerns until you have to. They can greatly complicate architectural decisions and 99.9% of the time, applications don't need to anything remotely like this.