This is structured logging. Stubbornly insisting that "structured logging" === "map" is dumb and ignores a large fraction of use cases where performance matters.
In this use case using maps doesn't solve any problem, requires at least one allocation, and requires hashing each key. This is not even an interesting discussion.
I can see the case for flat logging, aka. key value logging, as an optimization for very, very performance critical code that needs to emit string logs. That however, isn’t mainstream in my experience. The far, far more common case is logging in code with complex data-driven behaviors where the data is structured (more than one level, not flat) and where forensic debugging via logs is a critical activity. If that’s not your world, you should only be interested in it if you’re interested in the community at large. If you’re not, that’s cool.
I think you seem to be arguing that the end result should be a "map"-like structure, whereas the other commenter is arguing about the interface to the logging library not being based on maps. These are not the same and taking maps in the interface is likely to incur allocations, yes. Having to specify your key-value pairs without maps is the only downside to not taking fully constructed maps in the interface.
Adding the application/component code to do ”good logging” is tedious. Friction in the interface decreases the probability it will be done well, and consistently. I think the interface matters, and while it’s a second order problem it does impact system quality in the long run.
Just my opinions here. I don’t question the value of slog as it sits, just could have been better for the community at large is all.