Thank you for taking this on! This is shaping up nicely 😄

I was originally thinking to tackle this at a different level, by basically composing a new callback from set_ignored_hooked_blocks_metadata and insert_hooked_blocks that we'd then pass as third argument to instances of make_{before|after}_block_visitor where we'd previously passed insert_hooked_blocks (or no third argument at all, since it's the default).

function set_ignored_hooked_blocks_metadata_and_insert_hooked_blocks ( &$parsed_anchor_block, $relative_position, $hooked_blocks, $context ) {
	$markup = insert_hooked_blocks( $parsed_anchor_block, $relative_position, $hooked_blocks, $context );
	set_ignored_hooked_blocks_metadata( $parsed_anchor_block, $relative_position, $hooked_blocks, $context );
	return $markup;
}

/ * ... */

if ( ! empty( $hooked_blocks ) || has_filter( 'hooked_block_types' ) ) {
	$before_block_visitor = make_before_block_visitor( $hooked_blocks, $template, 'set_ignored_hooked_blocks_metadata_and_insert_hooked_blocks' );
	$after_block_visitor  = make_after_block_visitor( $hooked_blocks, $template, 'set_ignored_hooked_blocks_metadata_and_insert_hooked_blocks' );
	}
$blocks            = parse_blocks( $template->content );
$template->content = traverse_and_serialize_blocks( $blocks, $before_block_visitor, $after_block_visitor );

The downside of my approach is that it'll inject the ignoredHookedBlocks attribute not only into the REST API response, but also into the frontend-rendered markup, where it's not needed (although it's also not harmful). In this regard, your approach arguably better preserves separation of concerns. Its downside is that it's going to parse and re-serialize block markup twice for REST API responses: Once at the low level for hooked block insertion, and once at the newly introduced REST API response hook for ignoredHookedBlocks attribute injection. Repeated parsing and re-serialization of block markup is something we've tried to avoid on the frontend, as it did impact performance measurably; it's probably a bit less critical for the REST API.

So I think we basically need to pick which trade-off we're willing to make 😄