I don’t think the approach is fundamentally flawed, people use sorting to similar size whenever they can (see the existing stuff in torchvision and torchtext).

Not all batches are full. For example, if there are 100 sequence pairs of lengths (15,18) and the batch size is 64, one batch will only have 36 pairs. However, for large datasets the number of “non-full” batches is negligible; see linked post for a crude evaluation.

However,

this is problematic when you have batch norm (not that common in NLP, but an important caveat),
it also distorts other things - batch size 1 gradient estimates are 8 times noisier than 64. People have found all sorts effects from the last batch being smaller when the batch size does not divide the data set size (and asked here, and there is an option to drop some samples instead).
If you pool data for inference, you’re likely to have differing sequence sizes in your batch, anyway.

Personally, I would expect the 10% performance loss from padding/packing to be exaggerated for nontrivial models and a reasonable setup.
Neither did I have problems with the (lack of) cleanliness from unpacking / packing.
It would seem that clever hacks are like implicitly assuming all inputs are of the same length will drop on one’s foot (possibly of the next person working with the code) sooner or later. If one thinks of it as a trade-off between performance/code complexity vs. generality, requiring same-size inputs for a probably very modest gain seems dubious at best.
Best regards
Thomas