At the heart of this limitation is the security that comes from the PKI architecture that’s built-in. It’s set up well enough that most times you don’t even notice it exists - but consider that the client trusts certificates issued by IBM’s certificate authority, and IBM’s certificate authority has issued a CA Certificate to your BES server. Just as if you had acquired an SSL certificate from Verisign or another issuer, that Certificate is bound to the hostname of your web server.
Your BES Server uses its Certicate Authority certificate (issued by IBM and assigned to the hostname of your server) to digitally sign all of the content that originates on the server - Actions, Fixlets, etc. are all signed (transparently to you) using the server’s Private Key (where the Public Key is your masthead file, for practical purposes). This allows the clients to validate that your Actions, Fixlets, etc. actually came from your server and have not been tampered with en-route.
Your masthead file can, in fact, be changed; you just have to work with IBM Support to do that, because they have to issue a new certificate to your BES server. You’d also need to replace the actionsite.axfm on all of your clients (the actionsite.axfm is signed using the original masthead). If you will have your old and new servers online at the same time, there is a masthead switch fixlet that you can run from the old BES Server to point clients to your new BES infrastructure.
Of course, none of this changes the fact that you really, really should have the masthead issued to a hostname rather than an IP address for better flexibility. A masthead swap is useful for changing from one named server to another named server; usually you’d just update your server’s DNS entry to point to the address of the new server, but in cases of domain renames, mergers & acquisitions, etc. masthead swaps may be needed.