I think there are pro/cons for both approaches. Remember that generally you need to think about a layered approach.
First off, is this more useable, is it confusing the user, etc. More fields at one time may lead to more use confusion, typo frustration, etc. Perhaps the user gets frustrated and that results in them using a less complex password (theoretical in this case, but UX is very important for getting people to play along well with security). There is a UX benefit to having to go through less pages. Keeping to well understood flows and uniform design is also important to assist users in identifying phishing - if things are constantly changing or are different the user may be confused.
I would be more concerned about what is happening up and down the rest of my stack in this case. What else besides username is being used to identify the user? Are there browser cookies, browser fingerprints, etc. If all of these things only come into account for an authenticated user, you may wish to prohibit a high risk action until after authentication. If you have reasonable assurance of the user's identity then it may not as much of a risk in balance with the UX side.
My guess would be that in general when developers make this choice its not necessarily with security goals or security reasons in mind. It may be easier for their user flow or help desk to provide these links rather then give instructions that include login and then navigating somewhere. It may also make sense from the developers point of view to segment out each function like this.
I would generally like to see a successful authentication and then request re-authentication for a password change. I think this also provides more compartmentalization (removes identity from the picture) which probably would lead to less security related bugs; you are also restricting the privilege only to already authenticated users. I agree with some other responses that there is a risk oflockout/DoS with putting this function before an initial authentication.