Of course I think the Flickr API is the bee's knees. Just as a challenge though, what would a photo management application that exposed itself using the Atom API look like?
I got sucked into thinking about this in considering how RESTful the Flickr APIs really are, especially in light of point 4 in Paul Prescod's Common REST mistakes. Prescod recommends avoiding putting actions in URIs which the Flickr API seems to do in spades.
The key feature I'm pondering is how to retrieve metadata about a photo. Two separate URIs would solve the problem, at the expense of increased network traffic and increased API complexity. It would be nice if the same resource/URI could be queried for different representations. Yeah, I know clients are supposed to specify this in the HTTP headers, but really how many folks actually do. He Hao's REST Web Services : Best Practices article indicates the potential for a meta query word, but then tags its usage as "arguably RESTful". Given the nature of the Atom wonks, my guess is that the spec is pretty doggone RESTful from the start, so one wouldn't have to worry about this issue.
Thinking out loud, an Atom enabled photo gallery system would be a nice alternative application to weblogs. Easy enough for mere mortals to understand what it's supposed to do, practically useful, yet probably exercising all of the APIs power.