The issue in SharePoint 2007 was if you installed SharePoint as an account that
was not used by SharePoint for anything else, then deleted that account or
changed its password. For instance, if I was logged in as contoso\todd when I
installed SharePoint (more specifically when I ran the configuration wizard and
created the config DB) and then I changed my password it's likely you wouldn't
be able to add or remove any machines to or from that farm. The password of the
account that creates the config db is used as a hash for some encryption used by
your farm. If that password gets changed out from under SharePoint, well,
hilarity ensues. When a machine tries to get in or out of the farm, if it
doesn't have the right hash, SharePoint gets very upset.
You will not have this problem if you are logged in as one of your SharePoint
service accounts, like contoso\spfarm, when you create your config db. In that
example if you change contoso\spfarm's password you have to use STSADM to tell
SharePoint about the password so your app pools will run, or your timer job
service will start, or whatever is using contoso\spfarm. When you do that,
SharePoint also updates that encryption hash with the new password, so all is
well.
Alex is right, SharePoint 2010 is immune to this because of the new Farm
Passphrase. It's used to generate the encryption hash instead of the
installation account's password.