It's a fair question. Having a map-type has several benefits:
1. I can signal to my api's users that there won't be any repeating keys without having to write documentation
2. The type can be mapped correctly into the target language. Most languages have a map-type and so it's nice if you don't have to convert it yourself
3. No manual conversion also saves time in most cases, since libraries can do it efficiently in one step. Otherwise you get a list<X> from your library and have to turn it into a map. Not good for bigger lists in performance sensitive applications
4. The same is also true the other way around when sending data to the server
5. It saves space in many serialization formats like json. Instead of [{"key": "key1", value: "value1"}, ...] you get {"key1": "value1", ...}
6. It's nicer to read and debug
7. It's nicer to manually create/write those values in tools like graphiql to test queries by hand and those tools can even warn you if you repeat a key by accident
Just some of the things out of my head, I'm sure I've missed a bunch.
Yes (5.) is possible, but now your API type becomes "List of List of String" and you need documentation and examples to explain that every list will have two entries and the first one will be the key. On top of that, if you have a different types for keys and values you have an even bigger problem, because lists in graphql need to have one type for all elements.
And while you can use a uniontype (like String | Integer) to have strings as keys and integers as values, your user now ends up with an ugly typ in their code and has to untangle it by hand.
So the user will have to 1.) know about that it is supposed to be a map, 2.) untangle the list types in their code, 3.) convert it into a map while not mixing up key and value
Therefore I usually go with explicit key/value objects if it's okay for performance or go with a custom JSON type if performance trumps the rest.
1. I can signal to my api's users that there won't be any repeating keys without having to write documentation
2. The type can be mapped correctly into the target language. Most languages have a map-type and so it's nice if you don't have to convert it yourself
3. No manual conversion also saves time in most cases, since libraries can do it efficiently in one step. Otherwise you get a list<X> from your library and have to turn it into a map. Not good for bigger lists in performance sensitive applications
4. The same is also true the other way around when sending data to the server
5. It saves space in many serialization formats like json. Instead of [{"key": "key1", value: "value1"}, ...] you get {"key1": "value1", ...}
6. It's nicer to read and debug
7. It's nicer to manually create/write those values in tools like graphiql to test queries by hand and those tools can even warn you if you repeat a key by accident
Just some of the things out of my head, I'm sure I've missed a bunch.