Scott Mace is so right:

With a standard, one can have a standard server running independent of the Internet that one can test against.

Scott was inspired by Spanning Synch:

Building an application on top of Google Calendar (which is itself still in beta) [...] "building a house during an earthquake".

I'd broaden Scott's stability principle to any well-defined, stable API. It's easier to build an application on top of a stable (public, or standard, or external) database API than one you're developing as you go. I'm not sure whether it's better or worse when the developer making the API churn is on the same team or a different team as the developers using the churning API but it's bad either way. There are lots of techniques to try to enforce stability so that you're not building your application on quicksand and one of them is certainly to use a standard for an important interface -- it's a way of enforcing discipline one might not otherwise have.