TL;DR
You may be misunderstanding the security trade-offs that a YubiKey offers. All security controls involve trade-offs; YubiKeys with YubiCloud authentication involves key escrow.
Authentication with YubiKeys
Out of the box, YubiKeys are pre-configured to authenticate against the YubiCloud. The default mechanism appears to involve storing your AES secret key server-side. Yubico claims:
There is no access to AES secrets even for administrations of the backend KSM servers.
Even if true, I would expect any key-escrow system to be fundamentally vulnerable to physical threats and brute-force attacks. Assuming you trust Yubico to escrow your keys in the first place, anyone with physical control of the Hardware Security Module or its contents could mount an attack.
The bottom line is that if you use the YubiCloud authentication mode, you will be trusting Yubico with your secret key even if you change it. Changing your key only makes sense if you are using an alternative back-end for authentication, or if you believe your currently-stored key has been compromised in some way.
Password Protection in the Personalization Tool
What this feature is doing is providing an administrative password for preventing re-configuration of the key. You may want to look at the source code, but the "Configuration Protection" password is just that: a password to prevent unauthorized changes to the key. Section 3.2 of the API documentation says:
[T]his approach is targeting destructive attacks as the interface does not provide any means of retrieving secret information. The configuration interface is write only, and the term destructive attack refers to an opponent that wants to erase or modify the settings of a device.
In my opinion, this feature is most useful in preventing end users from misconfiguring or re-purposing an organizationally-owned YubiKey. Your mileage may vary.
