I found a workaround for this issue in my environment; not sure if it's applicable more generally for other mailservers that might trigger this WHD issue, but it worked to resolve the issue here. We had originally been on a non-Exchange email system when we implemented WHD (and POP3 worked fine with that mailserver, no extra carriage returns) and we had it set to POP3 retrieval. When we switched to Office 365 (i.e. Exchange in the cloud), I'm not sure if we just didn't notice the "Exchange" option in WHD, or if it's a new option, but either way, we were still using the POP3 protocol to hit Office 365 and still getting the extra carriage returns.
As an aside, heeding the suggestion above to make sure that the server was sending plaintext, I used a PowerShell command to ensure that any POP3 retrieval would be plaintext. That did not resolve the issue, so it's not an issue with plaintext versus anything else.
But I then changed the "Account Type" field from "POP3" to "Exchange 2010/2013" in the WHD email retrieval settings and that did the trick. I don't know if that "Exchange 2010/2013" option is new, or that we just didn't notice it when we switched to Office 365, but it worked to work around this issue at our site.
Note that the POP3 (and IMAP) protocols still have this bug (and those protocols should really work with Exchange servers too....and they will need to for servers that don't have EWS running), but those who are experiencing it with Exchange servers that do run EWS (whether on-premises or in the cloud) should be able to work around the bug by changing the retrieval protocol to "Exchange 2010/2013". In my case, I didn't even have to re-do the credentials or other settings: it worked immediately after I changed that "Account Type" field.