Plugins are a debt you take on knowingly
Every one solves a problem today and constrains an upgrade later.
A plugin is the fastest way to make a learning platform do something it does not do. It is also a permanent dependency on somebody else's continued interest in maintaining it, and that interest is not contractual. The calculation is not whether the plugin is good. It is whether the problem it solves will still be worth solving when the plugin stops being updated and the platform needs a security release.
The plugins that age well tend to be narrow. A tool that adds one report, or one question type, or one enrolment method has a small surface against the rest of the system and usually survives a version change with minor adjustment. The plugins that age badly are the ambitious ones, the ones that replace a whole subsystem or reach into the theme, because they depend on interfaces that move.
Before installing, it is worth asking who else runs it and whether it was updated after the last major release. A plugin whose last update predates the current version is not necessarily broken, but it is a signal about the maintainer's attention. It is also worth asking whether the requirement is real or aesthetic, because a surprising proportion of plugin requests turn out to be somebody wanting a different colour.
Keep a list. Not in the platform, where it will be lost in a migration, but in a document that a person can read: what is installed, who asked for it, what it does, and what would break if it were removed. That list is the difference between an upgrade that takes an afternoon and one that takes a fortnight of discovery.
The practical shape of this over a year is a small library rather than a project. Every plugin request produces one line: who asked, what for, what happens without it. Most requests never reach installation, because writing the second line honestly resolves a surprising proportion of them, and the ones that survive arrive at the decision with the reasoning already assembled. The library also means that when an upgrade forces a review, the conversation is about documented requirements rather than about who will admit to needing something.