An idea with great potential, I've been philosophizing along this same ways, separating the presentation and the core of the app you can architect better multi form factors with varying capabilities, get network transparency in post X11 world (wayland), allow compositionality of heterogenous UI-bound modules, skinning to death, automatic scriptability, easying look and feel evolution independently (without touching the functional cores). A GUI is that, an interface, capable of standarization, one example being the IFML of the OMG group, hinting some ideas, overbureaucraticed or not. So a presentation process has an interface to the user and there should be a protocol binding presentation and core app connection so could pilot the app with a toolkit or even a console REPL. I think this could decrease importantly the development effort of GUI user apps in long scale proys.
Currently, the humble CGI script is the market leader in loosely-coupled pipe-driven graphical interfaces.
I love the idea of being able to make apps in Go, Python, Node.js or whatever I want and piping to a separate view engine process. I started building something similar for Windows and OS X, but I got a little side-tracked with paying bills and such...
If your needs are extremely simple (e.g. graphical dialog boxes launched from a shell-script,) then there's zenity (gtk): https://help.gnome.org/users/zenity/3.14/ and kdialog (kde).
One nice side-effect of this is that now you can use languages like Brainfuck etc, which have no easy way to access toolkits, to write GUI applications
A manpage is not how you attract users nowadays.
A manpage might be just the right marketing channel for people who are really into piping commands.