OGC and interoperability

Unlike the business world, OSM does not view standards compliance as a goal in itself; i.e. if we are to use a standard, it must have clear an direct benefits for the project - otherwise nobody will code it or assign resources to it. While this does not apply to each and every OGC standard, on the whole they range from "cumbersome" to "useless" for OSM and thus are disregarded.

It is unlikely that the OSM server infrastructure itself should become "OCG compliant" in any way in the near future because the above mentioned benefits are unlikely to outweigh the cost in terms of implementation work and server load.

This does not, however, mean that you cannot use OSM in an OGC-compliant world - it just means that OSM is not going to provide OGC compliance for you on a silver platter. You can, for example, access several third-party WMS servers (see Wiki) serving OSM data, or you can install software to convert osm to shape files and vice versa. There's also an ogr2osm utility. The openrouteservice.org web site offers OpenLS-based geocoding and routing, and many more.

All these have in common that you either have to write/install software yourself, or use a - sometimes paid-for - service provided by a third party. If, for example, you wanted a WFS server serving OpenStreetMap data, you could import OSM data into a PostGIS database (see Wiki) and run an UMN map server off it, and so on. You are right in that the project doesn't provide that and is unlikely to do so any time soon, but any third party can do with our data what they want, including setting up OGC compliant services. (However, OSM has a very good history of accepting contributions of all kind - so if you think you can add OGC services to the OSM core infrastructure without any ill effects then step forward on the developers list and start coding!)