I've just stumbled upon this. IMO this functional deficit is a critical defect, not a minor bug.
Background: We've been using the old (deprecated) Warnings plugin for ages and it recently stopped working (incompatible changes in the Jenkins core) so we're now being forced to "jump ship" to the next-gen warnings plugin. I'm currently re-coding our (thankfully few!) groovy parsers to work with the new plugin ... only to find that the core functionality provided by the old plugin (the ability to parse the console log) doesn't seem to be supported yet.
That's a blocking issue for me; I had (foolishly) assumed that this plugin's functionality was a superset of the other plugins that it claimed to replace.
I've read the description above and the "for security reasons" argument has little credibility - these parsers are only configurable by someone with admin access and such a person can run any Groovy code they wish on the primary Jenkins node if they so chose (and/or can authorise groovy calls for use in sandboxed mode).
i.e. There's nothing inherently insecure about having an admin-approved snippet of groovy code being able to parse the console.
It's no different than if it was parsing a file of a build that'd run on the primary Jenkins node - it's all running in the same place, and the only thing that's running is 100% approved by the admin. By all means run it in a sandboxed environment where the parser is passed in the console and outputs optional warnings (and only those), but the code is admin-approved because it's admin-submitted.
I believe that there may be an argument for allowing the admin to choose whether or not a parser is limited to just the console, or just files, or both, depending on the groovy code they've configured (they might want to stop users from creating builds that use parsers incorrectly), but the ability to parse the console content is of vital importance; I'm shocked/disapointed that it's absent in a plugin that's been around this long, especially as this plugin is described as a replacement for the old warning plugin where this aspect "just worked".
IMO the suggested workaround to "re-code every single job you've got" is unreasonable; we've got hundreds of them and, as a Jenkins admin, I can't 100% rely on my users to correctly pipe everything into a file during evry build step - not all output goes to stdout, you need to capture stderr too and that's all too easy to forget; that's why it's important to scan the console itself - it's much harder for the user to mess that up.