Speck and Simon have the benefit of simplicity. Like RC4, Speck could even be memorized. It's like 30 years of block cipher design has been condensed into the smallest possible algorithm.
Simplicity is useful. I've seen on multiple occasions bugs in more complex algorithms, like ChaCha20. Test vectors don't help as much--or at all--when you're creating a bespoke CSPRNG as in the OpenBSD and Linux kernels that repurposes the core round functions.
Moreover, if we're talking about backdoors, then code complexity--even just sheer number of lines of code--is the spy's friend. For more complex algorithms it would be more practical to trojan COTS and FOSS software to, e.g., substitute an operation so you'd still get the same logical output but lose side-channel resistance.
I'm not an EE, but assuming all the standard reviews happen, I'd much prefer that hardware vendors use something like Simon. Hardware acceleration is the very definition of a blackbox. Hardware developers can copy+paste+munge as well as any software programmer, but there's rarely any subsequent external review. The value of simplicity just can't be overestimated here. Because hardware products lack the extra layers of transparent, open review, we really want to minimize the potential for accidental screwups. The simpler the algorithm, the fewer degrees of freedom they have to be creative.
The smaller block size and smaller key size profiles were dubious, but that's a judgment call. The NSA probably sees so much bad crypto out there that the Simon & Speck designers could have earnestly considered them a step up. Note that the debate about these weaker profiles was never about choosing them over some stronger algorithm. Rather, the alternative argument was that if a hardware design was so low-power and so low-bandwidth that those profiles were useful, it would be better to not have any crypto at all so nobody would have a false sense of security. From an engineering perspective I think most would agree with the latter; but as a practical matter commercial vendors no doubt will sell half-baked crypto in such tiny devices, and without a known quantity we'll probably be worse off. In any event, those weaker profiles have already been ceded.
Assuming the algorithms continue to hold up to review, I think it would be a net loss to lose Simon & Speck. And, frankly, I'm more suspicious of the motivations of, e.g., Chinese and Russian security services.
As for why the NSA designers haven't been cooperating as much as the community has desired, it's anybody's guess. AFAIU, these designs were something of a 20% project for these engineers and they're probably not getting much support from management for pushing these designs. I don't even think they work in one of the departments these designs normally come from; IIRC they've claimed they tossed it over the fence to one of those secret departments and got a thumbs up. But who knows. And it shouldn't matter, especially for something so simple. All evidence suggests that the NSA no longer possesses extraordinary skill when it comes to cipher and hash design, so provenance shouldn't color anyone's judgment. Academic and private industry designers can and have worked for security services, too.
Low powered hardware? You can give it more power. Why should security be sacrificed at all by IoT devices just to make them cheaper? Make them secure in the first place, point.
With today's speed, I'd go with a traditional Feistel cipher with moderately high security margins any time.
It's annoying that NIST approves standards with very low security margins - AES is an example of an algorithm with unnecessary low security margins, for instance. Speck and Simon are even worse in that respect.
Simplicity is useful. I've seen on multiple occasions bugs in more complex algorithms, like ChaCha20. Test vectors don't help as much--or at all--when you're creating a bespoke CSPRNG as in the OpenBSD and Linux kernels that repurposes the core round functions.
Moreover, if we're talking about backdoors, then code complexity--even just sheer number of lines of code--is the spy's friend. For more complex algorithms it would be more practical to trojan COTS and FOSS software to, e.g., substitute an operation so you'd still get the same logical output but lose side-channel resistance.
I'm not an EE, but assuming all the standard reviews happen, I'd much prefer that hardware vendors use something like Simon. Hardware acceleration is the very definition of a blackbox. Hardware developers can copy+paste+munge as well as any software programmer, but there's rarely any subsequent external review. The value of simplicity just can't be overestimated here. Because hardware products lack the extra layers of transparent, open review, we really want to minimize the potential for accidental screwups. The simpler the algorithm, the fewer degrees of freedom they have to be creative.
The smaller block size and smaller key size profiles were dubious, but that's a judgment call. The NSA probably sees so much bad crypto out there that the Simon & Speck designers could have earnestly considered them a step up. Note that the debate about these weaker profiles was never about choosing them over some stronger algorithm. Rather, the alternative argument was that if a hardware design was so low-power and so low-bandwidth that those profiles were useful, it would be better to not have any crypto at all so nobody would have a false sense of security. From an engineering perspective I think most would agree with the latter; but as a practical matter commercial vendors no doubt will sell half-baked crypto in such tiny devices, and without a known quantity we'll probably be worse off. In any event, those weaker profiles have already been ceded.
Assuming the algorithms continue to hold up to review, I think it would be a net loss to lose Simon & Speck. And, frankly, I'm more suspicious of the motivations of, e.g., Chinese and Russian security services.
As for why the NSA designers haven't been cooperating as much as the community has desired, it's anybody's guess. AFAIU, these designs were something of a 20% project for these engineers and they're probably not getting much support from management for pushing these designs. I don't even think they work in one of the departments these designs normally come from; IIRC they've claimed they tossed it over the fence to one of those secret departments and got a thumbs up. But who knows. And it shouldn't matter, especially for something so simple. All evidence suggests that the NSA no longer possesses extraordinary skill when it comes to cipher and hash design, so provenance shouldn't color anyone's judgment. Academic and private industry designers can and have worked for security services, too.