This approach is only necessary if we want to skip serialization of block support or apply styles to elements within a block.

We might take this opportunity to simplify it to:

const blockProps = useBlockProps( {
	className: clsx( {
		'is-open': openByDefault || isSelected,
	} ),
} );
const innerBlocksProps = useInnerBlocksProps( blockProps, {
	template: [
		[ 'core/accordion-header', {} ],
		[
			'core/accordion-panel',
			{
				openByDefault,
			},
		],
	],
	templateLock: 'all',
	directInsert: true,
	templateInsertUpdatesSelection: true,
} );

Why is this style necessary in the first place?

This was already present before the change...
I'll check if removing that style causes any visible effect
If that doesn't change anything then the workarounds below won't be needed

What is the reason for this change?

For accordion content block, this rule was preventing the margin from being applied for blockGap to work
This change lowers the specificity so that margin applied by blockGap could work

How about just removing margin: 0 here?

.wp-block-accordion-panel is just a div element, so I'm not sure why margin:0 is necessary in the first place.

Yes I'll try finding why was that added
ig removing margin: 0 shouldn't cause any problems & then the workarounds won't be needed too

As far as I've tested, I don't understand what this style is trying to fix - what specific problem does it cause?

When we set blockGap on Accordion content, the margin still remains when the accordion is collapsed
This rule overrides it to zero so that additional margin isn't applied for collapsed accordions (user would use block gap of parent accordion block to set that spacing), so the content block's gap would just affect the spacing between header & panel

I see, then, how about a selector like this? I'm not sure why aria-hidden is used in the editor and inert on the front end, but maybe we can unify this in a follow-up.

.wp-block-accordion-panel[inert],
.wp-block-accordion-panel[aria-hidden="true"] {
}