I can't seem to submit this as a comment replying to @MayankBargali-MSFT , so let's try it as an answer:
This behaviour "by design" is unhelpful, costly, and from many people's perspectives it is flat-out wrong.
Firstly it coerces an infrastructure component's design philosophy & implementation decision on to users of APIM & the importer - or forces unnecessary workarounds. It seemingly prevents the application handling these client errors in a uniform fashion, e.g. by returning a standard API error response. It may also make it harder for applications to determine how many callers are hitting this issue by fragmenting application-specific logs across infrastructure components.
Secondly, it is quite common for REST-based APIs to return HTTP 400 when a required query parameter is missing, so this preference SHOULD be supported by APIM and the importer.
Thirdly HTTP 404 risks deceiving developers and client software because many developers and a lot of REST client library code interprets HTTP 404 as a signal that the REST endpoint is not found, rather than the endpoint being found but requires a query parameter that was not supplied.
Fourthly if one insists that HTTP 400 is simply not valid for the omission of a required query parameter then arguably HTTP 410 is a better choice than HTTP 404 because unlike HTTP 404 it indicates that the URI (including the query parameters) in question is intentionally unavailable and that condition is expected to be permanent. And that speaks to the point that APIM and its OpenAPI importer should NOT be forcing design philosophy and implementation decisions that are significantly contested by API designers on to APIM users.