In bash? Good luck. Your main problem is that by creating two FIFO's per plugin daemon in your design, any long-running request in a plugin will hold up other requests to that plugin. Unless you go ahead and implement an async I/O stack or threaded architecture inside each plugin. (Starting to sound more like Node.js...)
He's using chipper sarcasm to illustrate the point that rewriting things "the Unix way" may produce a great troll fork on Github, but more up-front engineering is absolutely justified if you anticipate the need to scale.
To get more to the point, Unix pipelines in shell scripts are nifty but absolutely not designed to scale in the ways that a typical networked server process does.
I happen to agree with him; if the only point of hubot was to be a campfire bot with a plugin architecture, you could probably accomplish that in 5 lines of Ruby that would never see the light of day in a production environment.
