In case the server goes rogue and starts refusing to sign, the user can use their userRecoveryPrivKey to send the funds anywhere they choose. Because if this, the userRecoveryPrivKey is best suited to cold wallet storage.

Would you then assume that userWalletPubKey is a hot key (stored on the users computer eventually in a browser based local storage container)?

In case of an attack on the server responsible for serverWalletPubKey (where also the personal information of the user are stored [including the xpub == amount of funds hold by the user)), wound’t this increase the users risk of being an possible target (False sense of multisig security, comparing to cold storage / HWW keys)?

In the more likely event that the user forgets their password and/or looses access to their userWalletPrivKey as well as loses their recovery key, they rely on the serverRecoveryPrivKey.

When the user first sets up their wallet, they answer some basic identity information, set up a recovery password, and/or set up recovery questions and answers. This information is explicitly NOT sent to serve with the exception of recovery questions (although the answers remain with the user, never seeing the server). What is sent to the server is it's 256 bit hash used to identify the recovery wallet. The server then creates a 1025 bit nonce, encrypts it, stores it, and transmits it to the user's client.

I guess this will result in protecting the funds stored in this transaction entirely on the users identity information and eventually the optional recovery password, though I guess you are adding additional security by protecting via the server nonce from brute-forcing.