TL;DR - No, you shouldn't just ignore exceptions quietly.
Let's look at the assumptions.
I've learned to trust that many of the decisions in .NET were made by people who really know what they're doing, and there is usually a very good reason behind things they decide. But this one escapes me.
MS has some really brilliant people on staff, no doubt. They also have a number of managers and executives who are ... clueless, and who consistently make bad decisions. As much as we'd like to believe the fairy tale of the technically savvy scientist driving the product development, the reality is far more grim.
My point being, if your instinct tells you something may be wrong then there's a good chance (and past precedent) that it is wrong.
- That this is a technical issue
How to handle exceptions in this case is a human factors decision, not a technical decision. Loosely, an exception is an error. Presentation of the error, even if poorly formatted, provides critical information to the end user. Namely, something went wrong.
Consider this hypothetical conversation between and end user and a developer.
User: The app is broken.
Dev: What's broken?
User: I dunno, I click on the button and nothing happens.
Dev: What do you mean by nothing happens?
User: Look, I click, I wait, and I wait, and I wait, and nothing... it's obviously broken.
Our poor, fortunately hypothetical Developer now has to figure out what went wrong in the chain of events. Where was it?
Event handler notification -> Routine to handle the event -> Method triggered by handler -> beginning of asynchronous call -> the 7 layers of OSI networking -> physical transmission -> back up the 7 layers of OSI networking -> receiving service -> method called by service -> ... -> return reply sent by service -> .... -> asynch receipt -> processing of asynch reply -> ...
And please note that I've glossed over several potential error paths there.
After addressing some of the underlying assumptions, I think it becomes more clear why quietly suppressing exceptions is a bad idea. An exception and associated error message is a key indicator to the users that something went wrong. Even if the message is meaningless to the end user, the embedded information can be useful to the Developer in understanding what went wrong. If they're lucky, the message will even lead towards the solution.
I think part of the problem here is that an incorrectly handled exception will crash your application. By suppressing the exceptions, the application won't crash. There is some validity to this though since the point of async is to allow the application to keep working while data is being retrieved. It's not that much of a logical extension to say that if you could keep operating while waiting on the results then a failure in retrieval shouldn't crash the application either - the async call is implicitly declared as not important enough to end the application.
So it's a solution, but it's solving the wrong problem. It doesn't take that much effort to provide a wrapper to the exception handling so that the application can remain running. The exception is caught, error message thrown to the screen or logged, and the application is allowed to keep on running. Suppressing the exception implies that ignoring errors is going to be A-OK and that your testing will make sure exceptions never escape to the field anyway.
So my end assessment is that this is a half-baked attempt at resolving an issue created by pushing people into an asynchronous model when they weren't ready to shift their thinking to that approach.