The goal is to decouple the model (content) from the view (the apps that render the content).
For example, in the old way of doing things you might use Wordpress to host your corporate blog. But what if you want to put that content into an email too? Or an app page?
In the headless-CMS world, you write the content and store it in the headless-CMS DB. Then any client that wants to render it (your blog site, your webapp, the backend server that's sending email messages, etc) can pull the latest version of a particular piece of content, and render it.
I might not have been clear; it's for nontechnical people to manage data in a database. For example, writers on a blog site.
Edit: The original version of my comment which this poster was replying to, said something along the lines of "a GUI that lets nontechnical people manage a database", which was ambiguous.
No, the goal is to allow people with a different set of skills (content creators) to create content, even though they don't have database or engineering skills.
I'd used systems like this at every game company I've worked for to allow writers, game designers, and translators work on content without having an engineer in their dev loop.
For example, in the old way of doing things you might use Wordpress to host your corporate blog. But what if you want to put that content into an email too? Or an app page?
In the headless-CMS world, you write the content and store it in the headless-CMS DB. Then any client that wants to render it (your blog site, your webapp, the backend server that's sending email messages, etc) can pull the latest version of a particular piece of content, and render it.
A good example use-case is using something like https://www.gatsbyjs.org/docs/headless-cms/ to render a static site, based on dynamic content stored in the headless CMS.