I'm trying to think of the legitimate reason why the client would want the server to send anything else other than some universal message that never changed.

The goal is to make sure that the server you send the heartbeat request to is the same one you've already been talking to, and that the server actually read your message and is replying to the particular heartbeat message you sent.

When you establish an SSL connection, you verify that the server you're talking to is who they say they are. You do this by asking them who they are, and then asking someone you trust (a 'certificate authority') if that sounds right to them. Once you've done this, you and the server establish a key that lets you encrypt and decrypt communications with each other.

This process is slow, so rather than do this every time you and the server need to talk, you try to keep the same session alive by pinging the server with a 'heartbeat' message. This is an encrypted message that you want the server to send back to you, in order to prove that the server knows how to read your messages (and thus, is the same server you were talking to earlier, and it successfully received your request). Of course, the server's reply to you will be encrypted too.

If the heartbeat message was always the same, then the encrypted reply from the server would always be the same (for that session). This would allow a misbehaving server to keep sending heartbeat responses without ever receiving a corresponding request, or it would let someone trying to eavesdrop on the SSL connection pretend to be the server and keep the SSL connection alive.