I think they _might_ have thought a little farther than this; as far as I can tell this tool was _supposed_ to only boot images with the same security checks as the actual fused state of the console, and the issue was that the section header parsing code was vulnerable to a trivial attack which allowed arbitrary execution, which of course could then bypass the lifecycle state checks.

I'd extend your thesis to "you need to audit your recovery tools with the _exact same_ level of scrutiny with which you audit your production secondary bootloader, because they're effectively the same thing," which is the same concept but not _quite_ as boneheaded as you suggest.

Recently, I see this class of exploit more commonly, too: stuff like "there's a development bootloader signed with production keys" has gone away a little, replaced with "there's a recovery bootloader with signature checking that's broken in some obvious way." Baby steps, I guess...