Presumably this is only for accounts you are already logged into and want to change the password of, since change password forms usually aren't accessible unless you are already logged in.
However, the same domain may involve multiple account types. AWS and other popular websites have multiple types of accounts, different login methods, and different change-password forms, on the same domain. If all this URL does is redirect to one single page per domain, it won't work for cases of more than one type of login.
Also, it seems that password reset is a lot more common than just changing a password, so maybe this spec could be extended to that form, too?
If a website has more than one account type that the user might want to change the password for, it could add some sort of flow to ask which account was meant. If the user has more than one account at the website, that becomes up to the user to make sure they signed into the right one that they wanted to password change. If the website is aware the user may have more than one account (such as Google's account switcher), they could present the options directly then.
It seems easy enough to do the right thing in most cases, given how simple this proposal is.
So it'll be the same as it is now, except that there's a button to start the process of doing the non-standard thing. I think a little bit of extra work on the standard could result in a more standard experience, and less work for the user.
In order to change the password, you have to be logged in. So the website will have to redirect the user to a log-in form, passing along the change-password form URL when authentication succeeds. Then the user can put in the old password and new password, go through an optional MFA hokey-pokey, and get it changed.
If the intent is to speed up password changes, a few optional additions would be faster than the above. The spec could optionally allow (1) the account ID, (2) the user ID, (3) the old password, and (4) the new password. The response could be a challenge and consent request for the user, which the user could then affirm and submit.
The website could still dictate how this works, but the idea is that the password manager would pass along all relevant data in the initial request, eliminating the need for the user to enter it all manually, and eliminating extra page loads. But it requires no site-specific state on the client-side, because all requests would be exactly the same, to this generic URL. Whatever implements the spec URL on the server-side would perform the login and present the password reset challenge, pre-populated for the user.
This is not even an API. It is merely a proposal that wherever your change-password form lives, people should be able to get to it via this specific path, too. Perhaps this whole thing is a terrible idea, but either way the problem they're trying to solve is different than the problem you're trying to solve.
At last wrt. login and register for doing the "first" auth which is then stored in the authenticator, e.g. a username/password login).
These are all relatively common business requirements.
The web already has a perfectly good solution for arbitrary forms, and has had it for decades. Just use that.
Since the spec is intended for password managers and other user agents, it makes sense to have a standard location to access such functionality.
Also the page could be anything (i.e. doesn't have to be a redirect) so theoretically AWS could set up an account chooser that has links to all the appropriate places for your accounts