H.264 / MPEG-4 AVC
Pros:
-Has open source implementations of encoders and decoders.
-The audio, video, subtitling, and container specs is open and well documented

Cons:
-Has parts patented by a vast number of companies, so a single holding company for the patent load was created.
-Container and audio codecs were both developed by Apple, the spec audio is AAC, and the spec container is mp4, which is essentially a Quicktime MOV container.
-At some point in the near future, royalty payments will have to be made to the holding company by someone.

VP8/WebM
Pros:
-Has multiple free and open source implementations.
-Use VP8 video, Vorbis Audio, and Makrosta container, which are all free and open source. MKV and Vorbis have well defined open specs

Cons:
-The final standard of VP8 is defined by code, not a well defined spec. Essentially, as WebM evolves, movies will compatible with WebM-git-DATETIME, like HTML is moving to be.
-While open source, Google "holds the keys to the cathedral," so there is not that much community involvement in the central defining project.
-Probably uses some H.264 patents (FFMPEG reuses a large amount of their H.264 decoding functions in their implementation of WebM decoder.)
-TO MY KNOWLEDGE, NO DEFINED SUPPORT FOR SUBTITLES ( http://www.webmproject.org/code/specs/container/#demuxer_and_muxer_... )

This is not a "pro". Open source implementations of encoders and decoders simply ignore the fact that users in some countries require a license. It is left up to said users to get that license. People (especially in the US) could be caught unawares by this, and have to pay fines.

-The audio, video, subtitling, and container specs is open and well documented

"Well documented" is true, "open" is not, because to be "open" requires that implementing the specification is royalty-free. This is not the case with H.264.

Cons:
-Has parts patented by a vast number of companies, so a single holding company for the patent load was created.
-Container and audio codecs were both developed by Apple, the spec audio is AAC, and the spec container is mp4, which is essentially a Quicktime MOV container.
-At some point in the near future, royalty payments will have to be made to the holding company by someone.

A large number of cons have been missed out here. The most obvious one is that h.264 development costs have been recouped ages ago, and so now all of the money that royalties continue to bring in is pure cream, and a dead-weight loss on the economy. The second most serious con is the chilling effect on innovation that a heavily-patented codec has.

VP8/WebM
Pros:
-Has multiple free and open source implementations.
-Use VP8 video, Vorbis Audio, and Makrosta container, which are all free and open source. MKV and Vorbis have well defined open specs

That is well defined, the only problem is that it may have inaccuracies. For now, if any inaccuracy is found in the spec compared to what the WebM Project reference codec produces, then the spec will be changed to correct the discrepancy rather than the refernce codec. This is needed because the spec is new, and may still contain inaccuracies, and there is a need to preserve the validity of existing encoded files rather that freeze the spec right now.

Cons:
-The final standard of VP8 is defined by code, not a well defined spec. Essentially, as WebM evolves, movies will compatible with WebM-git-DATETIME, like HTML is moving to be.

Nope. The bitstream format, as instanced within the existing corpus of WebM files, and defined as the bitstream format produced by the webM Project reference code, is frozen. That is the webM format.

The only thing that is not frozen is the specification document for that format: http://www.webmproject.org/media/pdf/vp8-bitstream.pdf
... because it is 105 pages of complex and realtively new text, and it may still contain divergences from the frozen bitstream format it is meant to describe. Once those have been shaken out of the specification, it will become the formal specification, and this document will then be frozen also.

-While open source, Google "holds the keys to the cathedral," so there is not that much community involvement in the central defining project.

Nope. There is a pretty decent community and building momentum behind WebM, and a number of independent implementations of it. Where do you get this guff from, exactly?

-Probably uses some H.264 patents (FFMPEG reuses a large amount of their H.264 decoding functions in their implementation of WebM decoder.)

Probably not. There is a great deal of "common ground" video compression technology that has prior art (and is therefore not patentable by anyone), or for which applicable patents have expired. Piror to buying On2, as part of due diligence Google undertook a lengthy and what they describe as thourough patent investigation of VP8, and they gave it a clean bill of health.

Full quote from link: "WHATWG / W3C RFC will release guidance on subtitles and other overlays in HTML5 <video> in the near future. WebM intends to follow that guidance".

So, when the subtitles and other overlays requirements of HTML5 are settled, WebM will support them. There is plenty of capacity in underlying the format structure to do exactly that. This is a "pro", not a "con".

PS: despite repeated attempts to characterise it otherwise, WebM is both free as in gratis (no charge) and free as in libre (no royalties).

This is not a "pro". Open source implementations of encoders and decoders simply ignore the fact that users in some countries require a license. It is left up to said users to get that license. People (especially in the US) could be caught unawares by this, and have to pay fines.

Source code is speech, which is supposedly free in "civilized" nations.

Binaries on the other hand...

-The audio, video, subtitling, and container specs is open and well documented

"Well documented" is true, "open" is not, because to be "open" requires that implementing the specification is royalty-free. This is not the case with H.264.

Only in Europe, which is also the only place your definition of libre makes sense.

Essentially, as WebM evolves, movies will compatible with WebM-git-DATETIME, like HTML is moving to be.

Let me first say, WTF? The community is updating quality and performance of VP8 encoder. It means it would still be backward compatible. Have you seen recent activity going on on Theora ? They are just upgrading code while keeping compatibility. It is same here, VP8 I mean.

Essentially, as WebM evolves, movies will compatible with WebM-git-DATETIME, like HTML is moving to be.

Let me first say, WTF? The community is updating quality and performance of VP8 encoder. It means it would still be backward compatible. Have you seen recent activity going on on Theora ? They are just upgrading code while keeping compatibility. It is same here, VP8 I mean.

The fact that there are about to be a bunch of hardware VP8 decoders means that they won't change the binary spec. They might be able to get away with it if it was only being decoded through software but you can't simply thrown away hardware every 6 months.