This is a fairly secure setup in use in a lot of places. It's a server-sided certificate setup so it is very popular. It offers gradual security: mostly secure, but the users can make it more secure in some cases by making some configuration changes (and for certain types of devices you can roll those changes out automatically.) It is also nicer than TLS when it comes to password expiry and such, since you do not have to change client certs to change "passwords".
PEAP + MSCHAPv2 will be in use for the forseeable future due to Microsoft NAP (a.k.a. SOH, statement of health) not working over TTLS, IIRC.
The biggest current security worry in this setup is that it is hard, and in a few cases, impossible, to get the clients configured to validate the owner-id of the server certificate. It is easy enough on windows and Linux as they both allow the user to configure the necessary options. It is less a concern on iOS/OSX, which will lock in the certificate after the first join to the network so the opprotunity for AAA MITM is slim. It is a bigger concern on Android where Google has sat around with it's thumb stuck someplace impolite for nearly a decade rather than implement a simple GUI element on the WiFi config screen, meanwhile allowing the machine to pay no attention whatsoever to whether the certificate changes.
Another minor security concern is that clients do not tend to properly use an anonymized outer ID so their usernames tend to be visible in the clear. Configuring this is more widely supported than configuring validation; just about every client will let you do it, though on Apple products you have to build a mobileconfig because they didn't want to confuse their fashion-addled user base with too many options so they took that one out.