My phrasing may have been unclear: by "You could definitely get, e.g. gate area down vs. AES or ChaCha without sacrificing sane block/key sizes" I mean you can

My phrasing may have been unclear: by "You could definitely get, e.g. gate area down vs. AES or ChaCha without sacrificing sane block/key sizes" I mean you can make ciphers that achieve gate areas lower than AES's or ChaCha's without sacrificing decent block/key sizes. ("Down vs." was not the clearest; maybe it sounded like "down for".) As you note, and as I mentioned above, some standards processes have already picked some ciphers meant to be better for constrained environments than those two. The ones I know about (as a nonspecialist!) still use higher parameters than smallest versions of Simon/Speck. PRESENT, accepted by the same committee, has an 80-bit key and 64-bit block, for example, and eSTREAM has its 80-bit hardware profile. That's the "smaller primitives that still have sane-ish params" I was talking about. The smallest Simon/Speck variants go lower, and seem like skating too close to the edge to recommend and standardize, even if there's somewhere they're the right/only fit. After posting the comment you replied to, I found a PDF from IAD that suggested that the 32/64 block/key size was never going to be submitted to the ISO committee because they have a minimum key size of 80 bits, and 48/96 was canned out of technical concern about the 48-bit block. (Posted it as a self-reply (a...great-uncle? of this comment), because it was too late to edit.) What they wrote actually makes dropping the weaker versions sound a lot less contentious than the Reuters story does, though of course it's one party's version of the story. And the continued pushback from some countries to the 128/256 versions clearly has other causes. If you mostly just want to dunk on me, I'm sure I've said something wrong here, but not wanting to standardize very low parameters at least isn't the same as just not being aware of lightweight crypto.