(If you're already familiar with this debate and the various proposals, you can skip to the table of pros and cons at the bottom of this post).
Motivation
Drupal core releases are currently numbered “X.Y.Z”, where “X.Y” correspond to a major revision, and “Z” corresponds to a patch level. We assign no special significance to “Y”, and stable releases are not guaranteed to be (and in fact, never are) compatible with each other.
Whenever a major revision becomes stable enough to release, we enter a new period of development in the TRUNK of the CVS repository. During this time, we have no way to identify the next release. Currently, we call it “cvs”, “HEAD”, or even “the next release”.
All of these names have the terrible property that the code which eventually became 4.6.0 was called the "cvs" code at one point in time, as was the code that became 4.7.0, as is the code that's now on the way to be 5.0.0. If you read an older issue, forum post, email, etc, that talks about the "cvs" version, unless you've got an incredible memory and can map the dates (if there’s a date at all) to the eventually released versions, you have no idea what code they're actually talking about.
This naming/numbering scheme causes real-life problems for the Drupal community. Developers have trouble referring to specific code. Bug reports against the code in the CVS TRUNK are ambiguously identified. There are currently 2146 issues marked for "cvs" -- how many should be considered before we freeze/release the next stable release? We have no idea. Documentation can’t be written in preparation for the next release, since the version number has not yet been finalized. During the development cycle, there’s no way to identify the state of the core source in a way that contributed modules could test if a given change to the API will solve the problem or provide the feature that caused it.