Well as this article (which I didn't initially read) suggests, some cards support this and they use the word "explicitly" which implies that there is an "implicit" case. ATI and NVIDIA are going to be supporting this early optimization. I don't know anything that suggests otherwise and have read some internal docs. This extension also provides the capability to explicitly enable "early" per-fragment tests, where operations like depth and stencil testing are performed prior to fragment shader execution. In unextended OpenGL, fragment shaders never have any side effects and implementations can sometimes perform per-fragment tests and discard some fragments prior to executing the fragment shader.
I think this extension is worded in a way that may be somewhat misleading, though at least they've put "early" in quotes. The same goes for the (wiki, by the way, so caveat emptor) page on opengl.org that you've dug up.
There is no "forcing early z" in OpenGL. OpenGL does not have any such thing as an "early z" at all, so you cannot enforce it. The specification is very clear about when the z test happens, and it is not "early", it is after the fragment shader has run. Still, implementations are allowed to do something different as long as the observable result is exactly identical, and most modern implementations in fact do something different.
If you search the OpenGL specification for "early", you find 3 occurrences of "linearly" and two occurrences of "clearly" (because Adobe Reader has no notion of searching for whole words), but "early" has no appearance at all. In particular, the additions to chapter 3 in above extension spec are funny because for example section 3.12.2 does not even exist in my copy of the specification (it stops at 3.11). They must be using a different copy
A better wording would be that you can give a strong hint to the implementation which effectively forces early z test on implementations that do an early z test (or, on most mainstream implementations).
The thing is, a modern implementation would of course always like to do the z test early, because this saves shader work. Insofar there is no need to "force" it. It's trying hard to do it anyway. However, the implementation must still guarantee that the result is the same, which it can only do with some very harsh constraints (for example if the shader does not modify z, so it is already known what the value will be long before the shader runs).
Now, by using a qualifier that tells the implementation so-and-so, you give a promise (for example "depth will not change" for "depth will always be greater"), or in the second example that you've given, you ask for a specific behaviour.
By doing so, you give a promise to the implementation that you know what you're doing, and that you guarantee that whatever you do will not cause the results to be wrong if it performs the early z optimization. You can of course break your promise or do something that will not work with the behaviour that you request, but this is very unwise -- that'd be welcome to the land of undefined behaviour.
Taking your word on that promise, the implementation will of course do the optimization (that's pretty much guaranteeed). In a way, you could maybe interprete this as "force on", but it really isn't. It's more "enabling" or "allowing" the implementation to do something outside the specification.