Minor: Alignment on the arrow (for consistency at least)

Trying to think through localization impact here; would this be translated differently by language? We might consider at least including a translator comment to explain the intent here:

https://codex.wordpress.org/I18n_for_WordPress_Developers#Descriptions

For styling consistency I'd recommend not ending lines with the opening tag of an element and rather having these on their own line. Especially in the case of the line below with <SelectControl it helps readability to associate props with the opening tag and not losing context with the condition in which it renders.

return (
	<div>
		{ ( onOrderChange || onOrderByChange ) && (
			<SelectControl
				label={ __( 'Order by' ) }

We could probably test truthiness of the callback in the condition on the line above and avoid the dependency on noop. This also reads a little "clever".

You might consider Lodash's flatMap which I recently found in #3185 to perform much better than Array#reduce + Array#concat.

Further, we can use array spread syntax to simplify this a bit:

function getSelectOptions( terms, level = 0 ) {
	return flatMap( terms, ( term ) => [
		{
			value: term.id,
			label: repeat( '\u00A0', level * 3 ) + unescapeString( term.name ),
		},
		...getSelectOptions( term.children, level + 1 ),
	] );
}

This is a long line and difficult to read, I would suggest breaking it down a bit.

const options = (
	noOptionLabel ? 
		[ { value: '', label: noOptionLabel } ] :
		[]
).concat( getSelectOptions( termsTree ) );

You could also use Lodash's compact to drop falsey values:

const options = compact( [
	noOptionLabel && { value: '', label: noOptionLabel },
	...getSelectOptions( termsTree ),
] );

Can we get some unit tests for this?

Added :) they were missing at the time because I was not certain if a utils function was right for this case.

I don't think we want to rely on a strict equality check here; these two objects may in fact be different references while containing the same values for postsToShow, order, orderBy, categories. If we need to, we can use Lodash's _.isEqual for a deep equality comparison.

The flowRight here is unnecessary at this point (with a single higher-order component) and could be written as:

export default applyWithAPIData( CategorySelect );

If the div is not serving a purpose on its own, wondering if we ought to just return as an array, with the only gotcha being we'd have to add keys to each rendered element, but this would reduce the total number of DOM nodes on the screen and reduce indentation in the component:

return [
	<SelectControl
		key="..."
	// ...
];

Why was this changed to put array opening on a line of its own? This isn't a style I've seen common to WordPress, and adds quite a bit of excessive indentation and awkward arrow spacing.

It was a try to make things look more aligned while respecting phpcs rules. I reverted this change but unfortunately, I'm not seeing a way to make things more aligned and respect phpcs.

Just noting that we really want to check that a change in the attributes specific to the fetching of posts are the only ones we want to trigger a new request for; as implemented, a change to the block's alignment, columns, layout will trigger a new request.

Kinda feel we can drop the rest of the comment after the first comma, that's really up to the translator to judge for themselves, and the first bit should be sufficient for understanding the intent of the string.

Personal preference would be to drop the newline prior to this comment, feels in line with this ESLint rule we have enabled:

https://eslint.org/docs/rules/padded-blocks (never)

Inconsistency here with the previous condition, and also tabbed at least once more than necessary. Would suggest:

		onNumberOfItemsChange && (
			<RangeControl
				key="query-panel-range-control"
				label={ __( 'Number of items' ) }
				value={ numberOfItems }
				onChange={ onNumberOfItemsChange }
				min={ minItems }
				max={ maxItems }
			/>
		),

Personally not a fan of the name attrsTriggerRefresh vs. e.g. queryKeys/queryProps. Though the name could be skipped altogether:

const shouldRefetch = [ 'a', 'b' ].some( ( queryKey ) =>
  this.props.attributes[ queryKey ] !== nextProps.attributes[ queryKey ] );

(or the converse with shouldSkip and Array#every)

Leftover assignment of ret?

What happens while we're waiting for the data request? Should we do an early null return?

Missing Internal dependencies comment (also, if you want to be really consistent, the External one should use lowercase d 😅 ).

Since you have this spread, you can throw in onChange.

Should restore that space before the string 'core/latest-posts'.

If onOrderChange and onOrderByChange default to Lodash's noop, the function checks here can be dropped.

Would termsByParent[ '0' ] be more correct? Since it's dict key.

Some copy-paste that went wrong? 😄

Yes @mcsf I missed it, it was solved :D

I recommend enumerating the two options: desc, asc and rephrasing to something like: Whether to sort in ascending or descending order: 'asc'|'desc'.

Post parameter by which to sort posts.

buildTermsTree is in @wordpress/editor, this should be a WordPress dependency.

Moved to @wordpress/utils :)

Good catch @mcsf, blocks library shouldn't depend on the editor. 👍