At the time, Todd was testing with whatever the popular rop compiler was, and it wasn't able to chain anything using libc. Even on amd64 you can restrict which gadgets are available. Maybe you can find other approaches with a careful hand search, but I think knocking out the biggest exploit generator is hardly flawed in a practical sense.

People don't generate exploits using popular ROP compilers.

what are popular ROP compilers used for then?

CTF challenges mostly

so they're used in combination with already known exploits but you're saying no one uses them during the development of exploits?

No, they’re mostly toys and demos. They’re not an accurate representation of real-world exploit development.

oh i must be confused about what a CTF challenge is

CTF challenges are to cooking competitions what exploit development is to being a restaurant cook. There are time limits, practicality is less of a concern, and everyone knows that toy constraints are added because nobody wants to watch you stare at IDA for three weeks

Say, if hardware checked that RET transfers control to a place that's immediately preceded by a CALL instruction, would that help?

It would help but it wouldn’t solve ROP. I think it would probably be less useful than gadget reduction, honestly, since there are a lot of useful sequences after a call instruction.

It would not help at all. See (all of, but especially) section 5.4 of N. Carlini, A. Barresi, M. Payer, D. Wagner, and T.R. Gross, "Control-Flow Bending: On the Effectiveness of Control-Flow Integrity," in proc. USENIX Security 2015, https://www.usenix.org/conference/usenixsecurity15/technical...

That would disable certain mechanisms that are occasionally useful. For example, to implement user-mode context switches and function hooking.

ARM's Branch Target Identification does something similar to that (but for jumps & calls, not returns).

A shadow stack of return addresses would help.