Yep, the conclusions in this thread are correct. To summarize:
The X.509 Subject field "CommonName" is limited to 64 characters per RFC 5280, pages 120 and 124:
CommonName ::= PrintableString (SIZE (1..ub-common-name-length))
...
ub-common-name-length INTEGER ::= 64
SubjectAlternativeNames has no such restriction, and for DNS names is only bounded by the DNS maximum (255 characters). It is permissible to have an empty subject per RFC 5280, page 24:
If subject naming information is present only in the subjectAltName extension
(e.g., a key bound only to an email address or URI), then the subject
name MUST be an empty sequence and the subjectAltName extension MUST
be critical.
So one could create a certificate with an empty Subject, and a long DNS name in the SubjectAlternativeNames, and it would be RFC 5280 compliant. However, such certificates create known compatibility problems with some major user agents. Try https://no-common-name.badssl.com/ and https://no-subject.badssl.com/ if you are curious to see whether any given user agent fails to validate. Until recently, Chrome on Mac would fail to validate such a certificate.
To avoid creating compatibility problems, Let's Encrypt never issues with an empty Subject. Another approach, which should be broadly compatible, would be to insert a "junk" field other than CommonName in the Subject. We originally thought to do this by copying the serial number field into the subject, but it's been suggested that the Baseline Requirements would term this "Subject Identity Information,"
Subject Identity Information: Information that identifies the Certificate Subject. Subject Identity Information does not include a domain name listed in the subjectAltName extension or the Subject commonName field.
Since Let's Encrypt uses the CA/Browser Forum domain-validated OID (2.23.140.1.2.1) in its certificates, the certificates are not supposed to have Subject Identity Information:
{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) domain-validated(1)} (2.23.140.1.2.1), if the Certificate complies with these Requirements but lacks Subject Identity Information that is verified in accordance with Section 3.2.2.1 or Section 3.2.3.
So currently our plan is to support a CA/Browser Forum ballot allowing the dnQualifier attribute in Subjects without it being considered Subject Identity Information, and then start adding that in place of CommonName.
In the meantime, the workaround of including a shorter name in CSR's CommonName field works well (as the original poster discovered).
[Update September 2018: The dnQualifier ballot at CA/Browser Forum failed over compatibility worries. There may be another ballot at some point, but for now progress on this front is stalled]
