There is an impedance mismatch in the meaning of defaultAuthenticationMethod when parsing (legacy) relying-party.xml between V2 and V3.
As a specific example, saying defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" automatically means that SAML1 stops working (because that authentication method is never asserted for SAML1 flows).
In V3 we do not have a single defaultAuthenticationMethod but the V2 schema believes in there being but one (with, one assumes, fan-out across to the profiles behind it).
Ian has the details, but although the log message does actually say as much it can take some sleuthing (Ian and I for 2 hours) to bottom out the issue.
The Wiki has examples of doing this on RelyingParty (https://wiki.shibboleth.net/confluence/display/SHIB2/IdPRelyingParty now changed) and DefaultRelyingParty (https://wiki.shibboleth.net/confluence/display/SHIB2/Multi+Factor+Login+Handler).
I have a vague memory (but I cannot find any documentation to prove it), that at one stage setting this attribute was the suggested way to get an IdP to use the Password handler.
The suggestion work item here is that if we meet defaultAuthenticationMethod for <DefaultRelyingParty> (and possibly for <RelyingParty> and <AnonymousRelyingParty> as well) then we emit a suitable warning about “specific default authentication methods may not be suitable for all profiles”.
It is not clear what the correct solution to recommend to people is. If they really meant the change, and want what it meant in V2 then they will probably want to upgrade to a V3 relying party file. If they did it because they were following a recipe then they can probably be told to be formulaic and remove the attribute