Why does the PAKE ideal functionallity allow the keys to be the same when the passwords differ? My intuition for the security a symmetric PAKE is supposed to provide comes from the example of a login page. Both the user and the server know the password (assuming unhashed passwords), and the purpose of the protocol is to authenticate both the user and the server to each other using this fact, while simultaneously generating a session key known only to them and avoiding any man-in-the-middle attacks. Specifically, I thought that one of the key properties of a PAKE is that the user and the server would get different keys if they provide different passwords, so a malicious party attempting to log in would be thwarted if it does not know the password. However, this does not seem to be the case according to the security definition.
The standard UC functionality for symmetric PAKE comes from Canetti et al.

Notice (top bullet under the $\textsf{NewKey}$ query) that if one of the parties is corrupted then the adversary gets to choose the session key $sk$, regardless of whether the two parties provided the same password. By using two queries to $\textsf{NewKey}$, the adversary can set both parties' session keys to be the same. Why would the definition be chosen to allow this? If the passwords differ, the functionality could instead have been written to give the adversary the power to choose only the compromised party's key, and not the honest party's key.
The paper contains text that explains why this is OK. I quote:

The main idea behind the FKE functionality is as follows: If both participating parties are not corrupted, then they receive the same uniformly-distributed session key, and the adversary learns nothing about the key except that it was generated. However, if one of the parties is corrupted, then the adversary is given the power to fully determine the session key. The rationale for this is that the aim of key exchange is to enable honest parties to generate a key that is unknown to an external adversary. If one of the participating parties is corrupted, then the adversary will learn the generated key (because it is one of the participants), and so the security requirement is meaningless. In such a case, there is nothing lost by allowing the adversary to determine the key.

However, from your question, I think I understand what you are worried about. If the adversary $P_k$ can set the value of its key with $P_i$ and with $P_j$ then it could seemingly behave like a man-in-the-middle between $P_i$ and $P_j$. However, this is not the case. Specifically, $P_i$ knows that its key with $P_k$ is $sk$, and when communicating with this key, it knows that the communication is with $P_k$ and not with $P_j$ (and vice versa). When $P_i$ wants to communicate with $P_j$, it has a different session key.
Bottom line, the reason that this doesn't matter is that the identity of the other party is given together with the key.
One more note: it may not be absolutely necessary to allow this, but there's no reason to disallow it. Disallowing it may rule out protocols that are perfectly fine. Therefore, it's better to allow it if there's no reason not to.