While plugins that could access the current geometry, g-code, process settings, etc., at various stages would be *extra* handy, probably the easiest to insert initially would be python or more generally shell command support to postprocess gcode before sending to the printer.
shell support would ideally provide a few wildcards mapped to various parameters, gcode could be written to a /tmp location and that path passed as an argument. While a full and flexible plugin API would be nifty, even just providing the ability to run a shell command and pass it some parameters would be enough for most gcode parsing purposes.
A much more broad API would be nice if it had access to Process Settings, current build platform geo, supports, etc. I'm currently manipulating process settings files externally - they're easy enough to parse, modify and rewrite, but being able to access the current process settings and modify them in programmatic ways, or create custom support structures or custom skirts, could open up powerful new functionality. I'm sure there are developers out there that would contribute alternate and custom infill patterns if hooks were available to do so.