At least most plugins don't affect Geany stability unless they are activated, so the impact of a "rogue" plugin is confined to those who use it, and they can turn it off. (Note, the plugin DLL is loaded and some code run to fill in the Plugin Manager dialog, but plugins shouldn't do anything major unless activated)
Definitely plugins should not delay the main thread, in particular blocking IO to anything slow, even if it doesn't stop. Plugins should use the Glib asynchronous IO facilities or separate threads (but note Geany is not thread safe, so you can't call Geany functions from those threads).
This last makes the issue of subprocesses being used to answer autocomplete or formatting or whatever somewhat problematical. Geany should not be blocked until the plugin gets an answer, but what should it do in the meantime, and its not re-entrant, so injecting replies later becomes problematical.
This last was one of the major blocks to previous efforts, no good asynchronous solution has been found yet.
And the alternative of using the subprocess to supply the symbol information for the Geany symbol management, from which Geany can quickly create the autocomplete list, hits the stumbling block that the symbol management has only a subset of symbol table functionality (most specifically Geany has no lexical scope handling or include file tracking), so accuracy is lost, and many irrelevant symbols get included in the autocomplete list.
And similar concerns apply to things like accurate indentation determination, or formatting.