The only reason why the 3.3.3 milestone was marked as completed is because leaving the milestone open interfered with our ticket reports for 3.4.1. (I forgot that milestone closures are reflected in the timeline.)
Generally speaking, we assign tickets to the next minor milestone if they are reporting an immediate regression. So, a regression in 3.2 that comes up during the development of 3.3 would have been assigned to 3.2.2, as happened here. In this case, we went so far as to close these tickets with a commit against the 3.2 branch. We do this sometimes mainly for housekeeping reasons, and so if there is the need for a release, we are more prepared. But since nothing triggered a release of 3.2.2 (a sufficiently critical bug or something security-related), we just closed the milestone. This is helpful for tracking purposes. We could have just as easily deleted it and re-assigned all of the tickets to 3.3. We just didn’t in this case.
Edit, adding more background: It is worth noting that we always strive for version branches to be as stable as possible. So, if you are running the 3.2 branch and always kept it updated, you might be running something “more stable” than the 3.2.1 stable release. These kinds of extra fixes do often get into a branch after the final point release for that branch, and thus are not released.
We have released formal packages on rare occasions — 3.0.6 was released at the same time as 3.1.2. In general, we have tried to maintain the second-newest branch (e.g. 3.0) until the current development branch (e.g. 3.2) has reached “beta” status. We didn’t announce the availability of 3.0.6, but anyone running the 3.0 branch could at least have updated to those fixes via official channels.