I used to have to deal with situations like this quite often, as I was escalated support in a large exchange provider.
Here is how I would approach this problem, but these are probably right up there with the most annoying to troubleshoot as phantom/random client problems (as they are always ridiculously hard to track down).
1st- You have done some great first steps, so great job attempting to tackle this, you have done allot of the smart steps to try
1 - My main guess would be there is another client/phone, something setup that is doing this, and there was a user based forward created there. I say this as you have checked/disabled much of the server side settings.
- To check this try to check/temporarily disable all past computers, current phones, tablets, etc that this user may be using, or have used. Use get-logonstatistics for that user to see if there are any connections that you cannot identify "Get-LogonStatistics -Identity email@example.com" Look at that log and see if there are machines that dont look normal/ones you know about.
2. If you see nothing out of the norm, or nothing that you can identify, next I would try disabling certain connection types, so you can again see if any clients are maybe causing this. In essence I would normally go down to just OWA connections (disable POP/Imap, MAPi/Activesync). Once you take out all the clients this should tell you definitively if it is client related to server related.
3. Finally if none of the above works, bite the bullet, export the user data and create a new mailbox using the same parameters. We would do this late at night, to avoid data loss, but since you are onprem, you should be able to export prior to any deletion, so your downtime should be minimal, just make sure you export, delete and purge, rather than restore. I would also point out you will want to do a PW reset here, as if it is a rogue client, if you give it the same logon name it could just re-connect. That should give you all new settings/connections that will hopefully fix your issue.
I KNOW this sucks, trust me i do. Especially if there are any litigation hold issues going on, but 99 times out of 100 this will fix your problem if you cannot identify it.
Does this happen for *only* meeting requests, or other types of items as well? Have you checked the Delegate settings (those are different from the ResourceDelegate exposed via get-calendarprocessing), Outlook rules, transport rules? In general, running a (detailed) message trace on one such request should give you and idea why it gets forwarded. It might just be a case of "hidden" rule, which you can delete via MFCMAPI or similar.