I'm not sure introducing a new property here is the best path. If we allow hiding the header here, will we also introduce various other properties for hiding activity panels, notices, etc on each page?

It seems like CSS may be an easier solution and more accommodating for more cases.

I'm not sure introducing a new property here is the best path. If we allow hiding the header here, will we also introduce various other properties for hiding activity panels, notices, etc on each page?

I would say 'yes' as demand for this emerges.
CSS seems fine to me also, and was originally my first solution, but I would prefer to do these things within the code if possible. Unless there is a strong reason for still rendering the Header in the background, but this may cause unexpected side affects as well, especially given it can be slot filled.

But given you are introducing the css body classes in your PR, I can forego going with that approach.

but I would prefer to do these things within the code if possible

I would also be in favor of handling these in the code where possible, but I'm hesitant to introduce knowledge around the various frontend components into the router/controller API as this could grow indefinitely.

Perhaps a more composable solution would be something good to add in the future, but I think this might be a lot for this PR to tackle.

I'm second guessing myself here just out of fear of possible side effects. Maybe for now we go back to your solution and introduce a property under pages that controls various aspects of the layout:

pages.push( {
	container: ProductPage,
	path: '/add-product',
	layout: {
		header: false,
	},
} );

That doesn't do a great job of mitigating growth of layout-specific properties in the controller, but at least puts these items under a more identifiable category.