Artificially large serial numbers create some negative performance implications. The CRLs produced by CAs (RSA, VeriSign, MS) that overload their serial numbers are frequently 50% larger than those who issue low, sequential (aka "serial") numbers (Netscape, UniCert, etc.). This can translate into extra minutes of waiting every day for users in large PKIs. If the US DoD followed this recommendation, their CRLs would increase by more than 20MB.
While this serial number overloading is syntactically permitted under the spec, I don't think the RFC needs to encourage this behavior unless there's absolutely no alternative to prevent an imminent SHA-1 meltdown. I'd prefer to see a SHA-1 solution that generalized to all of the other signatures people use (CRLs, documents, emails, OCSP, etc.).
I did spot one possible future change - the serial numbers
of the sample certificates are small (decimal 17,18,256). One
of the suggestions I've seen made for handling potential
hashing weaknesses was to prepend some randomness to those.
*If* (and I don't believe we yet know...I certainly don't) this
is sound guidance then we could reflect it in the samples (and
I guess also the security considerations). Something to think
about for later maybe. Actually, since large serial numbers
are pretty common, having at least one sample with a long
serial number would seem like a good idea in any case.