I'm not particularly fond of some parts of GTK+ & co since many of the libs and tools are too bloated for embedded use, and many of them depend on each other for no reason what so ever.
It may be fine for n900 and similar platforms with huge amounts of memory, (once we get rid of MMC and maybe have all that 32G as pure, directly accessible nand chips)
But, memory drives up cost of the appliance and sinks performance.

I believe the largest part of the phone market needs a root system measured in a few M not G.
Look at openWRT project, it's easy to configure, comes out tiny, and they developed it out of a need for a better router distro. Now every mfg and their mom is using it in at least a few of the higher end routers since it saves them money and users get a better product. The only real competition is from vxworks, (fits in 0.5M, openWRT needs like 2-4M) which might not last long since vxworks (on routers) is becoming infamous for some pretty major stability issues (although cred is due for such a small tcp stack)

Also, yeah, vcard is about the only standard that ever came out of the PIM world (ical doesn't count yet), and I don't believe there's anything wrong with using it as the main storage mechanism. A directory with all vcards, one contact per file should also work fine, since most people don't store more than a few thousand contacts anyway. (that's assuming a good filesystem, not a stupid one like fat32)
This is demonstrated quite well by rolo.
Git is also a good demonstration of how you can use filesystem features to ignore optimising your application data store, and often the end result is just as fast, more portable and still useful after many years. ie. if something does translate well to files, you should use files, since filesystems get better all the time.
Afaik people have also invented some ways of syncing vcards with other directories.
But... Vcard is extremely verbose, and, it's difficult handle all the extensions by other apps.

It'd be interesting to see what the consequences are of using something like unison to keep 2 Vcard directories in sync instead of parsing the files. I can't immediately see a problem with that if the application only touches the file when you actually edit the contact.
*If you've edited the same contact on both ends, there's never a straightforward way of solving the conflict anyways.

To summarise; I don't think we're done with PIM by a longshot, and it'd be interesting to see people experiment with the bottom layers of PIM instead of making fancy UIs that nobody will use after a year. Who knows, maybe, just maybe, we might get a standard out of it.