First of all, backwards compatible changes in libraries don't need application updates, by definition.
Second, if your library changes are backwards compatible, you can maintain separate release cycles - this is the normal way of doing things, actually.
Third, microservices simply don't allow backwards incompatible changes. This is a big hint that perhaps your libraries shouldn't do backwards incompatible changes either, as a matter of policy, even though doing them is theoretically possible.
Perhaps you meant deployment instead of releases, and were assuming static linking?
An often seen scenario is that small changes (a one-line bug fix, a tweak in behavior) in application functionality happen to be in the shared library code, so to get that fix to production, you need to redeploy all apps after the library change. Microservices allow you to redeploy just that single shared service.
Doesn't this simply mean that the deployment process is somewhat broken?
On a typical Linux distro, you run "apt-get" or "yum" to upgrade your Heartbleed-fixed OpenSSL, the package manage automatically restarts all affected daemons, and you're done with it.
Even if you deploy static images, a good build system should just re-run the linker after the library change and be done with it.
This means that even on Linux distro's the packages generally are not managed by apt-get or yum. This means that "shared libraries" don't necessarily mean Linux/C shared libraries, but are likely to be packages of Java/PHP/C#/whatever code that are re-used by multiple applications. This means that, for starters, you need to choose when and how you'll push this update to many different machines each running different applications. This means that "automatically restarting all affected daemons" isn't trivial - some of these services may have state (e.g. a deployment that also includes a change to a database), for some of them the downtime matters, you likely don't want to stop&restart all of the instances doing the same thing at once but rather do a rolling deployment. This means that some of the instances that need to be updated are out of your control/administration - you need to send the package to some other organization so that they can re-deploy it. Etc, etc.
Sure, a good build system should just re-run the linker after the library change and be done with it - that solves the packaging part. Deployment often is much trickier; some organizations have a good, robust deployment process but many (most?) don't.
The above statement is also not about performance. (It is about keeping "consistency by default" even if you do have performance critical areas.)