Isn't that exactly what a deps file does? Technically it's code, but it's serving the same purpose of keeping the URLs in one place. It seems like the only unique function that import maps serve in Deno is so that, instead of importing from "./deps.ts", you're importing from arbitrary identifiers. Which is fine, but I wouldn't say that import maps are ever needed in Deno. It was always possible to organize dependencies in a TS/JS file and import from its module.
The issue is that being code it's turing complete and not parsable by other tooling easily. Having it in a config format (yaml, json, etc.) is easier for other tooling to inspect.
One of the reasons behind ES module syntax was to make imports/exports statically analyzable. Sure, it's technically simpler and more portable to use JSON, but a tool that fits all more use cases isn't necessarily the best tool for the most common use cases. Given that all import maps are just maps of names to URLs, I see no reason why a JS module couldn't be trivially parsed to inspect what URLs are being imported and what identifiers are being exported.
This doesn't take into account how much tooling is not written in JS. There are lots of ecosystem tools implemented in rust, C++, bash, python, etc. that parse dependencies for things like CVE checking, version bumping, dependency graph analysis, etc. that don't want to have to implement a full JS runtime to get the list of deps. Python has requirements.txt and pyproject.toml, Rust has config.toml, etc. many languages keep their project metadata and dependencies in config formats instead of code for good reasons.
Why would you need a full JS runtime just to analyze what URLs are being imported? You don't even need a runtime for that. All that's necessary is to parse the AST, and in that case you don't even need an AST parser with full language support. It might not be as trivial for other language communities as writing a JSON parser, but it's not insurmountable or an unreasonable burden.
Honestly, I think the argument that one language community should lessen itself for the sake of another really bites. Using one language to analyze the dependencies of another really isn't a garden variety task. In the off chance someone really doesn't want to use JavaScript as their primary language for that task, what's so bad about calling an external runtime or parser from their language of choice?
I'm not saying I'm against import maps, because I think it's absolutely reasonable to want the features it provides, but I'm not being sold on any argument that they're necessary for almost anything. There's not a type of application I can think of that can't be written without anything an import map does.
I think your claim, that the Deno community is in some way "lessen[ing] itself" with this change, requires more explication than you've given it, not least because it's far from clear that providing a relatively straightforward onramp for existing projects and teams from Node to Deno will have any such effect.