For EAP/802.1x wireless security, that should not matter, as we only use it inside a tunnel (TTLS, PEAP) (SSL protected).

Popular EAP/802.1x-methods: PEAP+MSCHAPv2 or TTLS+PAP or TTLS+MSCHAPv2

BUT

In most networks, on most clients, certificate validation is largely absent
and difficult to enforce across all clients (BYOD!).

Moreover, many user guidelines explicitly ask clients to NOT validate the certificate.

A very simple, realistic attack scenario:

Place a rogue AP with the right SSID and connected to a fake RADIUS server in the target building/area,
and harvest logons at leisure.
No client has any chance to even notice the attack.

So, the tunnel is broken.

The fact that MSCHAPv2 is broken – it does not even really matter:
the attacker lures the client into talking to their rogue RADIUS server,
and of course can read all user credentials, regardless of encryption.

This is NOT a little irrelevant side note to the discussion of MSCHAPv2, which is, i agree, more intellectually interesting.
The MSCHAPv2 discussion unfortunately is an interesting academic but irrelevant side note to the fact that our de-facto wireless security practices render EAP/802.1x broken.