I will be the first to say that it's not as secure as it could be, but it's NOT the case that we're sending around cleartext passwords. VIA uses an HTTPS session to initially authenticate to the controller and perform a profile download. The password is sent inside that HTTPS transaction and is thus encrypted using TLS.
On the back end, the controller uses PAP to authenticate the user against a RADIUS server. Even here, it is not cleartext over the wire - it is encrypted using the RADIUS shared secret. RADIUS encryption is not really at the level of something like TLS or IPsec, and the security it does provide is directly proportional to the length and complexity of the shared secret, but a good shared secret does provide a reasonable level of protection - particularly since the network between the controller and RADIUS server is typically inside your datacenter, limiting the potential for someone to do packet captures on it (hopefully). A number of people also set up IPsec tunnels between controllers and RADIUS servers as an extra measure of protection - this is common in the DoD for example.
Beginning in 6.2, you're able to authenticate captive portal users using MSCHAPv2 (previously only PAP was supported). In 6.3, that same support extends to VIA web authentication (used for authentication to the WebUI for the VIA client download, and then used by VIA for the initial profile download). MSCHAPv2 will also be available to authenticate VIA IKEv1 connections (through xAuth). All of those use PAP today.
There are customers who simply refuse to enable PAP on their RADIUS servers for any reason, and although I think the danger is being overblown in this specific case, I understand why they have those policies. My usual advice is to create a shared username/password in the controller's nternal user database for the purpose of profile download, and to then move to certificate-based authentication with IKEv2 for the actual VPN usage. And of course once 6.3 comes out, we'll also have MSCHAPv2 support.
Hope that helps..