I think the first option to consider would be using a basic Gutenberg setup with:

diff --git a/php/post-types/class-block-post.php b/php/post-types/class-block-post.php
index e52a3fb..3a5cc81 100644
--- a/php/post-types/class-block-post.php
    b/php/post-types/class-block-post.php
@@ -214,7  214,8 @@ class Block_Post extends Component_Abstract {
                        'hierarchical'  => true,
                        'capabilities'  => $this->get_capabilities(),
                        'map_meta_cap'  => true,
-                       'supports'      => array( 'title' ),
                        'supports'      => array( 'title', 'editor' ),
                        'show_in_rest'  => true,
                );
 
                register_post_type( $this->slug, $args );

The 'Document' panel has most of the functionality as before.

But the 'block' UI would need a lot of consideration. Of course, we wouldn't want the ability to add any block. This UI only allows adding fields.

Update: per the comment below, it'd probably be better to disable block editing entirely.

By calling something like:

wp.blocks.setDefaultBlockName( false );

...we could prevent users from being able to simply type text into the UI (creating a paragraph block). This would then display:

Then, maybe this could add something like a 'block_lab_field' block, and that would be the only block available.

It looks like it's possible to disable block editing, as that doesn't apply to this:

wp.data.dispatch( 'core/editor' ).updateEditorSettings( { richEditingEnabled: false } )

.editor-post-text-editor,
[for="post-content-1"] {
	display: none;
}

In the PHP rendering function for the metabox circled above, it could simply output a container for the metabox, like <div id="bl-field-editor"></div>, and maybe a JavaScript const with any needed data.

Then, a separate script could render the metabox:

render(
	<FieldEditor>,
	document.getElementById( 'bl-field-editor' )
);

The new <FieldEditor> component would render the meta box. I'd probably port admin.block-post.js into that (or child components of it).

This wouldn't require a fundamental change to the block_lab post structure, like if we used a 'Field' block for each field.

@kienstra That sounds like a really good solution!

Thanks, Luke!

The metabox that's rendered as above can access and alter the post content directly.

For example:

const content = 'Brand new content here';
wp.data.dispatch( 'core/editor' ).editPost( { content } );
const blocks = wp.blocks.parse( content );
wp.data.dispatch( 'core/editor' ).resetEditorBlocks( blocks ); // Apparently this is needed so that the new content value isn't overwritten.

Then, the new content should be available with:

wp.data.select( 'core/editor' ).getEditedPostContent();

This should ideally allow the meta box that was previously rendered with PHP to be rendered with React, as described above.

Just like in the PHP rendering function, how it gets the post and parses it:

...the React implementation could parse the post content from:

wp.data.select( 'core/editor' ).getEditedPostContent();

There are still several challenges, like getting around how Gutenberg handles metaboxes. This approach wouldn't need its actions, like REQUEST_META_BOX_UPDATES.

This would function more like an alternate post editor, not a meta box.