Obvious thing: Some security vulnerability is found which gives attackers access to your system or so.

Or: There is some bug which gets active let's say after year 2013 or after 10k mails or so.

Or: (I don't know Sparrow so not sure if this applies.) You have created/build some app-specific content/database (like have done all your mail tagging with Sparrow) so you want to re-use it on future Apple hardware. Now assume that Apple introduces some new architecture (like an ARM MacBook) or makes some incompatible API changes in future MacOSX versions. Either you can't upgrade your hardware/OS or you will loose the app-specific work.

Etc.

Everything valid - but as time passes there is sometimes just no way around upgrading your software. The fact that there could be an immediate problem was ignored by me, that's true.

Since they want to keep it alive (in its current state) I believe they'd fix something critical.

The first two are valid, but in the specific case of Sparrow, all the "state" is held in the mail provider(GMail via IMAP) or FB, which is nice.

For something as critical as email, "fine until Apple changes anything" is not good enough, given that Apple has a habit of changing things.

Yes but worst case scenario is you are forced to switch to a different client not that you lose any data. So actually not that critical.

"given that Apple has a habit of changing things."

Apple doesn't have a habit of changing things. If anything, I feel that Apple is too conservative when it comes to making changes.

If Sparrow would be your only option to access your mails this would be true.

I think the broader point that doesn't analogise so well with cars is network effects and compatibility.

Even cars from the 1950s are compatible with modern roads, also they can have a lead additive put into the fuel, or the owner can convert the car to run on unleaded petrol.

If your program is old and closed source (in this context , old cars are basically open source since they can be repaired by anyone with relatively standard knowledge and tools).

I never used Sparrow, but I'll assume that at least they worked with standard email protocols like IMAP and POP3 making a switch to another mail client feasible. Imagine instead that they had used some proprietary (and possible patented) web service API. Then their users would really be in trouble, and this is a sort of model many startups seem to be going for.

A lot of the complaints are about the fact that the Sparrow team had promised push notifications for the iOS client "with or without Apple". Now we get nothing.

I know, I know, don't buy an application based on promises, buy it based on what the application currently offers. Wise words, I have learned.

One worry is since iOS is so dependent/tied to the app store for updates or reinstalls, if the developer pulls the app from the store, you can never redownload it, and you are then stuck trying to maintain a copy that you backed up and hoping you don't lose the file. And if you don't plug in to a PC you wont be able to reinstall the app. This happened to me with smule and "Magic Fiddle".