Is JPAKE over SSL/HTTPS overkill?

We have an API that runs exclusively in HTTPS, any unencrypted traffic is dropped.

We want to add public-key encryption to some of our methods (like login, payments, and so), by making the client generates locally a key pair and sends the public key to the server (one time). Similar to what services like Whatsapp do with their end to end encryption.

So far no issues with it. But in the mess and confusion around the PSD2 in the EU, our legal department is enforcing IT the use JPAKE to safely generate an AES session key, that the client will use to encrypt a public key generated locally before sending it to the server. Wich to me seems like overkill. Let me explain why:

JPAKE prevents active man in the middle attacks because the high entropy key derived in the protocol includes a secret shared beforehand using a different channel, in our case since is a mobile app, over SMS. In which is assumes the attacker has no control, and this is wonderful over insecure channels like HTTP. Here’s the thing tho, if we are using HTTPS and we have an active man in the middle attack, it could only mean 2 things, the attacker stole the private key from the backend or the attacker has control over the client to prevent the validation of the certificate with the certification authority. In both cases, IMHO, there is nothing JPAKE can do or any other type of protocol, since our server is compromised or the client is compromised. Am I missing something?

BTW, I’m all for overengineering security, but in this case, there is a high cost of implementing this, and there is also the cost of the SMS.