The other answers (Sam and Josh) cover most of what you need to know, but just adding a few extra points.
Before that however, Josh's point about the API not offering features is worth repeating. It's quite incorrect to say things like "OpenGL has vertex buffers" or "D3D has shaders", and was just as incorrect back in the day when you used to read things like "D3D doesn't have a stencil buffer" or "OpenGL has polygon offset". Your gfx hardware has features and the API exposes them; if your gfx card doesn't have a feature no amount of exposition in the API will give you it (unless you use some form of software emulation, which you really don't want to do) and if your gfx card has a feature but the API doesn't support it then you can't use it either.
Moving on with the extra stuff.
D3D has more sensible management of multiple monitors/multiple gfx cards, which can't be underestimated with some end-users.
Explicit memory pools in D3D9 or below were nice (aside from the dreaded D3DERR_DEVICELOST) and it's vertex buffer API is much cleaner and clearer and easier to use. Separation of layout specification from data specification was the right decision IMO. GL has improved with attrib arrays and VAOs but it's still not all the way there.
D3D also guarantees a single consistent shader compiler for all users and on all hardware, whereas each GL implementation has a different shader compiler. The Effects framework is also very nice.
D3D generally has better quality drivers than OpenGL. That's pretty critical.
OpenGL has extensions. That's something of a double-edged sword, as while you can get access to newer vendor-specific features earlier, you may end up with a mess of multiple codepaths all doing broadly the same thing. You make your own choice about which side of that tradeoff you're happier to accept.
OpenGL still has some nice things that D3D is missing. The accumulation buffer (on hardware that accelerates it) can do some neat things; D3D11.1 is apparrently finally going to get logic ops on the framebuffer.
glCopyTexSubImage is very nice in cases where it's implemented properly (which should be everywhere as Doom 3 used it) and D3D has no direct equivalent, to pull another specific example out.
OpenGL is capable of providing software fallback for things required by the spec but unsupported in hardware (not all things however) whereas D3D will normally give you a big ugly crash or error. Another tradeoff where you decide (although I still have nasty memories of a Geforce FX - which supported NP2 textures as required by the GL 2.0 spec - going back to full software emulation without warning if you actually tried to use one...)
OpenGL tends to maintain backwards compatibility through revisions of the API (I'm ignoring core contexts here) whereas D3D does not. There are arguments for and against each philosophy that it's probably not appropriate to retread here; just something to be aware of.
OpenGL still has bind-to-modify whereas D3D does not; you operate directly on the object (or pass it as a param) instead. The OpenGL way tends to mess up any state filtering you might be doing, IMO.
They're the main big ones I can think of right now; nothing too earth-shattering but enough to tip a decision.
Finally, it's also incorrect to state that Android, mobile devices, the PS3, etc use OpenGL, because they actually don't. They use GL ES which is in some ways a subset of full OpenGL and in other ways quite different (and on the PS3 anyone concerned about performance uses libgcm anyway).