Why implement onDestroy() if it is not guaranteed to be called?

According to the android Activity Lifecycle, the only callback guaranteed to be called (if an activity ever leaves the Running state, which is typically expected) is onPause().

So, I must assume that there are scenarios in which it makes sense to implement onStop() and onDestroy() although they are not really guaranteed to be called.

I understand that onStop() should be implemented when it's possible for an activity to return to the Running state via the Stopped state (why would it do that instead of returning directly is a different question).

But the need for onDestroy(), when I can place all cleanup/state-saving into onPause(), is unclear to me.

Can you describe a real-app situation (i.e. not analogy to driving a car etc.) in which it would make sense to implement onDestroy()?

onDestroy will be called if you explicitly call finish(); yourself.

Your main activity calls startActivityForResult on a map activity.

Map activity with a LocationListener, the user clicks the map and selects say a local restaurant.

The activity then , sets up some extras to be sent back to your main activity, it then explicitly call's finish(); on itself and in the onDestroy kills the LocationListener and other variables you had invoked.

Just found this in the docs

onDestroy() = The final call you receive before your activity is destroyed. This can happen either because the activity is finishing (someone called finish() on it, or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method.

Can you describe a real-app situation (i.e. not analogy to driving a car etc.) in which it would make sense to implement onDestroy()?

When you want to capture a configuration change. It's all in the SDK: http://developer.android.com/reference/android/app/Activity.html