In fact, I would prefer to handle responses to the Return-Path address manually (as mailgun does not do anything useful with such replies anyway) -- it is not that many of them. However, when it seems that Mailgun ignores h:Return-path headers and forces its own address as the Return-path header. Not good...
Sometimes people have auto-response message set to 'My new address is ...' -- these are extremely useful for keeping the mailing list clean and up to date. Another example is Captcha tests that some people add to protect their mailboxes from spam -- we would prefer to see such requests and actually solve the Captchas manually (to make sure our messages are delivered to more people) rather than simply being unaware of that happening.
Current unsubscribe links are 190+ characters long.
First, you are contradicting your own recommendation: "Long links may cause bounces. Some ESPs will block emails with links (or any consecutive text) longer than 99 characters."
Second, such links look ugly in the text versions of the email.
I agree with Sasha on the fact that shortening links can make more harm than good. However, I would still recommend to implement a database-based solution, i. e. store all messages ever sent and reference them by ID. A 64-bit identified would be sufficient for these purposes, you can use 96-bit for extra security -- that would lead to just 16-character long base64-encoded identifiers -- way better that the current 150-characters monsters. In the era of super-cheap storage space I do not think it will be a problem to store such information for a very long time.