Why is recipient hashed in this Sign/Encrypt/Sign proposal? Own research

In my journey into trying to understand PGP, and public key signing and encryption as a whole, I came across this answer on CE. It is an answer to a question with the title: Should we sign-then-encrypt, or encrypt-then-sign? Although this satisfies my original quest, it has an interesting link to an article called: Defective Sign &amp; Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML.. The article as a whole explains why "naive sign &amp; encrypt" systems are not as secure as most people think. Also, it proposes some solutions to the issue.

Question

A proposal which caught my attention from section 5.2 Sign/Encrypt/Sign of the article.


  Surprisingly, we can get an effective repair for S&amp;E, if Alice signs
  and encrypts the plaintext, and then she signs the ciphertext, too:

A ---&gt; B   :   {{{msg}a}B , #B}a

  
  (Here, #B means Alice hashes Bob's key, not his name.)
  
  This message means:
  
  
  Inner Signature: "Alice wrote the plaintext;"
  Encryption: "Only Bob can see the plaintext;"
  Outer Signature: "Alice used key B to encrypt."
  
  
  [...]


Is there any cryptographic / security reason why Alice would Hash Bob's public key? If I would implement something like:

A ---&gt; B     :   {{{msg}a}B , B}a


(B is Bob's public key, not hashed)

Would I still benefit from the security offered by this fix?

Background

I'm in the research phase of developing a messaging platform based on public-key encryption. My first intention was to use the OpenPGP standard. However, this standard alone would make it impossible to identify the sender until the message is decrypted. I want to offer end-to-end encryption, but at the same time, offering my servers to verify the sender is a registered user.

Off course, this could (and will) be done by client - server authentication. But even in such a case, using openPGP and authentication alone, a client can still misbehave:


  PGP's strongest security option is naïve Sign &amp; Encrypt, so PGP is
  vulnerable to surreptitious forwarding:

A ---&gt; B   :   {{ "The deal is off." } a}B
B ---&gt; C   :   {{ "The deal is off." } a}C



The server wouldn't know that Bob is illegally forwarding Alice's massage and gladly forward the message to Charlie on Alice's behalf.

I know that most of this can be prevented on the application level. Like e-mail is doing with authenticated SMTP and fields like From: and To. But as an experiment, why not fix these issues directly in the cryptography protocol? I think, the server reading the intended receiver's public key would be a nice solution.
I don't fully understand the notation in that link you posted, but as far as hashing the public key instead of signing it directly, some public keys are pretty long, making signing expensive. Public keys for RSA can be 4096 bits, which is too long for most signing schemes. Hashing the public key allows it to be signed more efficiently without losing security.