Agree w Gavin Mogan, "The issue is bigger than it sounds though." I titled this - UX as User eXperience, but that's only part of the problem. Daniel Beck's suggestion of a new update site seems onerous, tho. I am only vaguely familiar with the inner workings of Update Center or pluginManager; some thoughts..
The case of pmd plugin is perhaps a "best-case scenario". (my take) The developer found his plugin's functionality has been entirely superseded by another plugin, decided to deprecate it, voluntarily marked it as such and provided clear instructions in the source README on how to proceed. They did "all the right things".
The problem is those instructions are not passed along to the user via the Update Center or pluginManager UI; it's just gone 403 to the user. A regular user of Jenkins may not know how to get to the Github repo to investigate this or discover the alternate locations to manually download and install as a workaround, at least until the repo disappears too.
It is possible this can be overcome procedurally in some form. Perhaps a new release is made with an empty package so the entry remains but is useless to install. This is perhaps the easiest case to tackle. A new class of tag [ Deprecated/Decommissioned/Unsupported ] could be of use too.
The second case I am familiar with is the tfs-plugin. In this case, the plugin has a security vulnerability ( SECURITY-1506 / CVE-2020-2249 ) which was not addressed by the maintainers, but was actually removed by Jenkins maintainers as it does not meet the OSI open source license requirements - INFRA-2751. In this case, there's no indication in the Update Center/ pluginManager why it's no longer available AND there's no indication in GitHub there's anything wrong by policy or vulnerability.
In the case of tfs-plugin (where using tfvc), the user is not presented any alternatives to the plugin. A lack of SCM step effectively renders Jenkins useless for its intended purpose (ps: a poor a workaround is to use the `tf ` cmd line), resulting in a poor UX and reputation for Jenkins, not Microsoft. Lesser impairments perhaps for buildstep/wrapper plugins.
I suppose there's another scenario where Jenkins maintainers pull a plugin not for a license violation by rather the plugin contains an egregiously dangerous vulnerability (eg: malware, bitminer, etc.). Then what? It remains available and undocumented in the jenkinsci GitHub.
I'm sure the Jenkins maintainers are aware of additional scenarios.
In the latter two scenarios, again is it possible to overcome this procedurally? Would it possible to show the plugin entry in the Update Center / pluginManager, with a banner similar to UNAVAILABLE / Adopt a Plugin, linking to the Security Advisory that forced the withdrawal of plugin while retaining the entry (and maybe restricting the download) ? That would not involve any cooperation on the developer's part, though the repo would remain without warning. The banner could be a useful mechanism to warn existing plugin users of the license violation (which may impact their continued use).