Perhaps a good solution here would be introduce an onUnload() method to Plugin.java as a dual of onLoad().

The plugin's lifecycle would then look as follows:

1. The plugin is constructed
2. The plugin's onLoad() method is called (dependencies are already loaded at this point)
3. The plugin's onEnable() method is called (every other plugin is already loaded at this point, but not necessarily enabled)
4. Server is running
5. The plugin's onDisable() method is called (other plugins that depend on this plugin are already disabled, but still classloaded)
6. The plugin's onUnload() method is called (other plugins that depend on this plugin are not classloaded anymore)

This way Citizens will still be able to access classes from the addons in the onDisable method.

Obviously JavaPlugin can implement the onUnload() method using an empty body, or a default method on the Plugin interface could be used.

If Sentinel is disabled outside of a full server shutdown, that is erroneous. Any users that intentionally caused that to happen would be told "yeah obviously that broke it what did you expect". Same for Citizens, same for any&every other Citizens addon (I note, a lot of plugins function in whole or in part as Citizens addons, and they're all broken by this change)... same for most plugins. There's a reason for the giant red warning labels on "/reload", and a reason that plugins like Essentials even actively add extra warning messages when a reload is done.

I would be shocked if Citizens was the only case of this change breaking. I know for a fact a lot of plugins have two-way interoperation akin to Citizens. It's a core part of how plugin development works.

The PluginDisableEvent wouldn't really help - when Citizens shuts down, it saves all data for each NPC... some of that data is supplied by Sentinel (or whichever addon). It needs to be able to save that data. The only way to use PluginDisableEvent here would be for Citizens to save and shutdown the moment any plugin that depends on Citizens is disabled... which would be an awkward hackaround, not a solution - and likely to create its own new issues. (Individual unhooking doesn't work - everything saves at once into one file, it can't be separated... separating saves per plugin would be a massive scale of rewrite for literally hundreds of developers (Citizens is primarily an API for other plugins to add onto, rather than a full-featured system on its own, and a lot of plugin developers have used it - including a lot of small/individual developers, running their own servers and using Citizens as an API to power things like NPC-driven quests unique to their server... every last one of them would need to build their own systems for separated saving), that would also introduce significant bugs on top of invalidating all the convenience/cleanliness/stability/bug-prevention/etc. benefits of the unified save system).

"Plugin jars are still loaded in memory before the shutdown finishes" doesn't seem like it should be undefined behavior - especially for plugins that are explicitly interoperating with each other, and have even marked that via the Depends system.
Note that I'm not saying they have to remain loaded forever after disabling, just like... if all plugins are being disabled (as happens during shutdown, or even the "/reload" command), disable them all first, THEN unload, rather than actively unloading individually after disabling. I don't think individual unloading solves any issues, but it absolutely does create issues.

I disagree this is a bug.

There is a reason disables are done in reverse-depend order and we have PluginDisableEvent — so plugins can unhook each other.

Right now you are accessing a disabled plugin when you should not be. You can easily see how this would be an issue if you consider the scenario where the server is not reloading or stopping, but merely the Sentinel plugin is disabled — it would be disabled yet you would still be trying to use it during normal server operations.

Just because there was some old undefined behaviour for a number of years, doesn't mean it was correct.

Please consider using https://hub.spigotmc.org/javadocs/spigot/org/bukkit/event/server/PluginDisableEvent.html as a workaround.