While what you say about the vulnerabilities of AES is true, it is very easy to modify AES to remove these weaknesses, and in a way that still allows the use of the special AES instructions of CPU ISAs like Intel/AMD x86-64 or ARM Aarch64, so that the decreasing of the encryption/decryption throughput would be very small.

There are several ways to achieve this. An example would be to replace a few of the XOR (additions modulo 2) operations that introduce subkeys between the AES rounds with another kind of addition instructions, e.g. with addition modulo 2^64.

These additions do not commute with the operations in the Galois field used by AES and they completely destroy the system of equations in that Galois field that is equivalent with the standard AES, making impossible any algebraic attempts at breaking AES. Moreover, if the additions would replace XOR in irregular places, that would make some of the rounds distinct from the others, breaking an attack that depends on all the rounds being identical. By replacing quasi-randomly the XOR operations with either addition modulo 2^64 or addition modulo 2^32 it is possible to make all the AES rounds distinct, with no pair of identical rounds and with only a negligible throughput decrease.

Also using the usual hardware AES instructions, it is simple to implement the Rijndael variant with a block size of 256 bits, which is much stronger than the standard AES with a block size of 128 bits (this has been described in an Intel application note when they have introduced the AES instructions in the Intel Westmere CPUs, in 2010).

So any possible advances in the cryptanalysis of AES will have effects only for the decryption of old recordings of encrypted information.

Future encrypted information will be easily protected against any advances with only software changes.

I don't think there is much to be gained by Rijndael-256 (it requires 2 AES-NI operations with a shuffle in between anyway).

There are more promising Feistel-like constructions on top of AES operations such as Areion: https://eprint.iacr.org/2023/794

Any extension of AES to a 256-bit block size would need to use at least a double number of AES-NI operations, but it will also process a double amount of data, so that is not the problem.

The shuffle of Rijndael-256 is suboptimal, being a derivative of the shuffle designed for an 128-bit block, so it is certainly possible to devise something better than that when designing specifically for a 256-bit size. Rijndael-256 has only the advantage that it is a quasi-standard mode, which has passed some cryptanalysis during the AES competition.

I have not studied Areion, but at a first glance I agree with you that it seems promising.

Exploitable mathematical structure arising purely from the concept of an iterated cipher is probably what Nick meant there by "an actual mathematical break". SHACAL-2 is also an iterated cipher with a relatively simple round structure.

Pretty much all block ciphers (and therefore their derivative constructions) are iterated.

The SHACAL-2 permutation though is much more mathematically unstructured than AES. It's an augmented ARX unbalanced Feistel design (w/ additional non-linearities). Hard to imagine you could reconstruct any usable mathematical structure in that mess. It also has a strong key schedule which is not vulnerable to related-key attacks (AES is) which is by design due to its hashing application. 512-bit key space too which allows for easy nonce integration.

Most block ciphers iterate the same round function, but this regularity is destroyed by using distinct round keys in each round.

The only vulnerabilities of the iterated construction appear when a weak method is used for generating the round keys from the cipher key (i.e. when the so-called key schedule is weak), so that there are predictable relationships between the round keys.

There exists an alternative (and equivalent) construction for a block cipher, when the same key is introduced in all rounds, but in this case all the round functions must be different from each other (instead of iterating the same function).

Ironically, the reason SHA2 isn't reachable by the attacks that broke SHA1 is the simplicity of the SHA1 message schedule, which was also by design due to its hashing application.

SHA1 has a sloppy key/msg schedule. They could have just done a random permutation of words and been safe - it would have even been cheaper than what the ended up doing. Such as what BLAKE does.