The block-based content is an idea that has been around for a long time and is embodied in several CMS's. Concrete5 has them baked into its core, ExpressionEngine and Craft CMS have the "Matrix" fields, Wagtail has "Streamfields" (as another commenter mentioned), most of the hosted CMS's now have it (Weebly, Squarespace, etc), some of the flat-file CMS's and static site generators have it (Kirby and Lektor off the top of my head), and even Wordpress has had it for a while via the amazing "Advanced Custom Fields" and "Flexible Content Fields" plugins. (And wordpress is about to get a lot more block-y with their new "Gutenberg" editing interface, although it still spits out one big chunk of HTML which means you don't get the front-end markup advantages that you do with a true block-based system).
As a developer, there are 2 advantages I've found to the block-based approach:
1) The editing interface can be custom-tailored to the content and the non-technical users who are editing the site via a GUI interface can be more "guided" through the data. E.g. a photo gallery can have repeating list of slides and each slide has separate image + caption fields. This is hard to do with a single WYSIWYG editor (Worpdress uses "shortcodes", for example, but those are a terrible UI for most non-technical users... the whole point of a GUI is to not have to use code)
2) The front-end HTML+CSS markup can more easily be customized around the content fields. Using the image gallery as an example again... since each photo + caption of a slide is a discreet content field, I can insert that into any photo gallery markup I want. If the input data is itself HTML (as it would be from a WYSIWYG editor), I don't have that ability (unless I parse the HTML I guess, but that is terribly brittle and making a ton of assumptions about the generated HTML that will probably change depending on WYSIWYG widget version, where the content was pasted in from, etc).
* Concrete5: http://www.concrete5.org/
* Craft: https://craftcms.com/features/matrix
* Wagtail: https://wagtail.io/features/streamfield/
* Kirby Builder: https://github.com/TimOetting/kirby-builder
* Lektor Flow Blocks: https://www.getlektor.com/docs/models/flow/
* ACF/FCF: https://www.advancedcustomfields.com/add-ons/flexible-conten...
* Wordpress Gutenberg: https://wordpress.org/plugins/gutenberg/
As a developer, there are 2 advantages I've found to the block-based approach:
1) The editing interface can be custom-tailored to the content and the non-technical users who are editing the site via a GUI interface can be more "guided" through the data. E.g. a photo gallery can have repeating list of slides and each slide has separate image + caption fields. This is hard to do with a single WYSIWYG editor (Worpdress uses "shortcodes", for example, but those are a terrible UI for most non-technical users... the whole point of a GUI is to not have to use code)
2) The front-end HTML+CSS markup can more easily be customized around the content fields. Using the image gallery as an example again... since each photo + caption of a slide is a discreet content field, I can insert that into any photo gallery markup I want. If the input data is itself HTML (as it would be from a WYSIWYG editor), I don't have that ability (unless I parse the HTML I guess, but that is terribly brittle and making a ton of assumptions about the generated HTML that will probably change depending on WYSIWYG widget version, where the content was pasted in from, etc).