Also, it's not clear it makes much sense, even if you don't have that requirement - in just about every company, you want the helpdesk / IT department / some other central authority to be able to do password resets, which means that the central authority has the cryptographic ability to impersonate any user in the company. (Maybe this triggers logs, but protocol-wise, they can still read and write messages.) So E2E isn't really helping you; you might as well just encrypt all the messages to a key held by the central authority.

E2E is great for conversations between members of the public, where there isn't a central authority that determines identities, and where if you forget your password, the right way to regain access to the conversation is to meet your conversation partner in person and re-exchange cryptographic identities with them, end-to-end.

(I'd buy the argument "You should design all your protocols E2E first, and then add logging/escrow, instead of designing them less secure and bolting E2E on later," but Skype for Business already exists without E2E so that's a lost cause in this particular case.)

Message confidentiality between businesses. Did you perhaps think SfB only works between users in the same organization?

I'm having trouble finding all the docs for setting up Skype for Business federation but it looks like the latter. Since "end" here I think means the business and not the individual user account (for the same reason - all the compliance logs, all the password reset abilities, etc. applies to conversations with other businesses), if they do trust-on-first-use certificate validation of the other business, isn't that already as E2E as you're going to get?

Yes? Doesn't the client connect to exactly one server [pool], which hosts exactly one organization?