I think there are a lot of wrong assumptions of how things work internally in this report, which makes it hard to decipher what the actual problem is. Let's get some things straight:

• A plugin will not require more CPU power if there is any leftover audio from before stopping playback. This cannot overload your system.
• OpenMPT clears all of its internal audio buffers that are sent to plugins when restarting playback.
• OpenMPT tells plugins to flush their internal buffers when restarting playback, which some plugins don't do. When they don't, you hear e.g. reverb tails from before stopping playback slowly fading out, but it is not related to the CPU usage of those plugins, and it doesn't create any more CPU usage than a freshly triggered note after resuming playback. However: The process of restarting plugins may cause some of them to take long a long time to re-initialize. It's the opposite of what you observed: Telling the plugin to clear its buffers makes it take more CPU time in fact.

If you are talking about what I described in the third point, the only option to improve this is to not clear plugin buffers, which may eventually happen when we implement a mode where OpenMPT's audio output is constantly running. If you tried to describe something different, then I didn't understand it.

Well, what's happening is this.
After stopping playback of a pattern by clicking on MPT's stop button, MPT faithfully immediately halts all audio playback. Generally i will make edits, but this doesn't matter. When i press either the Play Pattern button or Play Song button, leftover audio continues to "release" for lack of a better word, while the plugins try to play the notes at the beginning of the pattern. There has be some processing going on, on some level, because the resulting audio layers (those releasing and those starting) are so numerous that the audio starts off choppy. As the old, released audio "finishes out," the choppiness goes away.
(One workaround i have is to lower the sample rate that openMPT plays like to 32000, but some plugins don't like that, and they or the plugin bridge will crash.)

You are right — i'm assuming here, and maybe falsely. But these are educated assumptions. I don't know what you know...

leftover audio continues to "release" for lack of a better word

These are indeed the plugins that do not follow the VST standard 100% and do not clear their plugin buffers when being told to do so. So the option you requested would not help there, as OpenMPT already asks the plugins to clean their buffers. Typically this left-over audio will be a reverb tail.

However, it is extremely unlikely that this reverb tail causes audio choppiness: Whether the source that was fed into a reverb consists of one, ten, one hundred or just leftover voices does not matter in terms of how expensive the reverb is to compute. Once the note has been fed into the reverb, the reverb will do its magic until it becomes inaudible.

There are two typical causes for problems when resuming audio playback in OpenMPT:

• An audio driver that takes a while to initialize properly. Typically this is completely independent of whatever plugins are loaded and the audio should actually not be choppy.
• Restarting the plugins (and cleaning their buffers) takes longer than expected. An option to do the opposite of what you requested - to just keep the plugins running and never clear their buffers - might be more useful here, and in the long run it's something we want to have (optionally), as it's more akin to what other DAWs do.

Without knowing which audio driver type you use (WASAPI? ASIO? WaveRT?), which other audio settings are used, which plugins are involved (plugins with big sample libraries might be clearing their sample cache and thus cannot start new notes immediately), and what the choppiness you describe actually sounds like, there is little more I can do to recommend a workaround or even take any action in the OpenMPT code.