It's nowhere near a complete server administration product that will let you avoid the terminal.
Perhaps for simple tasks but I fail to see the purpose.
So, yes, you're right - a lot of work still needs to be done, but Cockpit itself seems to be an adequate base, just need to add support for managing commonly needed services at least at a rudimentary level though (MySQL/PostgreSQL, Apache/Nginx/lighttpd, Postfix/Dovecot/exim/cyrus, etc).
The real advantage of it is that it allows installation of hosted engine easily, and a 'single pane' overview of a host (oVirt Node status without using nodectl, etc)
Since Cockpit wants to deal with dbus, the push is for other utilities (postfix, snmpd, etc) to publish relevant information over dbus, rather than teaching Cockpit the format of each and every configuration file on the system.
I wrote the Tuned plugin for Cockpit, and I maintain the oVirt plugin. I gave a talk at Devconf about plugin development, which is extremely easy, but the Cockpit team is small. It's very easy to write plugins for it, but even easier if they expose dbus.
That said, the cockpit API (http://cockpit-project.org/guide/latest/api-base1) makes handling files/processes from client-side Javascript in plugins simple. It's just that you'd need yet another config file parser...
Do you have a link to a video of the presentation?
It was essentially "here's how to use React to build a cockpit plugin from the ground up -- it's easy"
I'm a Python/Go backend developer, mostly, but Cockpit is easy enough that even I can write plugins for it. The workshop basically walked through the git tags in https://github.com/evol262/cockpit-boilerplate
cockpit-ovirt has a "Hosted Engine" tab which is an otopi parser. You'd find it to present exactly the same questions/options as "hosted-engine --deploy" in 4.0/4.1, with ansible and otopi deployments and a new UX in 4.2 which isn't a 1:1 representation of the questions asked.
Once Hosted Engine is deployed, the oVirt cockpit plugin can show the complete status of the HE cluster, put nodes into local maintenance, the whole cluster into maintenance, etc.
But it was far from finished and required a lot of work. I ended up having to go to the terminal to solve things a lot of the time.
So being a Fedora/RHEL fan I will definitely try cockpit with libvirt or ovirt and keep an eye on how it develops. But I also expect the same issues I saw with Kimchi, being forced back to the terminal to solve issues the gui can't do, or for some reason gets stuck on.