The language reference doesn’t make explicit guarantees about the performance of maps. There’s an implicit expectation that maps perform like you expect hash-tables to perform. I don’t see how a performance guarantee would avoid being either vaguely specified or inaccurate.
Big-O complexity is a poor way to describe run-times for maps: practically speaking the actual clock time is relevant and complexity isn’t. Theoretically, maps with keys from finite domains (such as ints) are trivially O(1) in space and time, and maps with keys with infinite domains (such as strings) require hashing and the specifics of equality testing to be included in the cost, which makes inserts and lookups best case O(N log N) on average (since the keys have to be at least O(log N) in size on average to construct a hash table with N entries. Unless you get these details right in the specification it’s going to be inaccurate, and the benefit of getting it right isn’t clearly worth it.
To provide guarantees about actual run-time rather than complexity it’d be also be difficult: there’s a wide range of target machines, as well as the confounding problems of caching and garbage collection.