Why isn't an edge-map graph implementation used in practice?
Assume we are dealing with the representation of a weighted graph. I will use Python as the programming language to illustrate the points, which will remain true largely if another programming language is used.
Let us call the graph representation raised in the question &quot;hashmap from edges to their weights&quot; or &quot;edge-weight hashmap&quot;. I would agree that an edge-weight hashmap is seldom used to represent a weighted graph.
One overwhelming reason is that compared to edge-weigh hashmap, it is usually preferred to use the following popular variation of adjacency list, which I will call &quot;adjacent hashmaps&quot; or &quot;nested hashmaps&quot;. The entire graph is represented by a big hashmap $g$, a.k.a. the outer hashmap, which is a collection of $(v, g[v])$ pairs, where $v$ is a vertex and $g[v]$ is a smaller hashmap, a.k.a. the inner hashmap. $g[v]$ is a collection of of $(u, w)$ pairs, where each vertex $u$ is a vertex that is adjacent to $v$ and $w$ is the weight of edge $(v,u)$.
An example

$\begin{array}{c|c}
 \text{Nested Hashmap} &amp; \text{Edge-weight Hashmap} \\\hline
  \begin{array}{l@{}l@{}l@{}lll}
\{\\
\quad1: &amp;\{2:2,&amp;4:5\},\\
\quad2: &amp;\{1:2, &amp;3:14, &amp;4:5, &amp;5:4\},\\
\quad3: &amp;\{2:14,&amp;5:34\},\\
\quad 4: &amp;\{1:5, &amp;2:5, &amp;5:58\},\\
\quad 5: &amp;\{2:4, &amp;3:34, &amp;4:58\}\\
\}\end{array}                &amp; 
\begin{array}{lllll}
\{\\
\quad(1,2):2,           &amp;(1,4):5,\\
\quad(2,1):2, &amp;(2,3):14,&amp;(2,4):5,&amp;(2,5):5,\\
\quad(3,2):14,&amp;(3,5):34,\\
\quad(4,1):5, &amp;(4,2):5, &amp;(4,5):58,\\
\quad(5,2):4, &amp;(5,3):34,&amp;(5,4):58\\
\}\end{array} \\
\end{array}$
The alignment of data entries above is meant for easy reading of Python code. By the general nature of hashmap, the actual storage locations of the entries in a hashmap are sort of unpredictable.

Comparison of complexity between nested hashmaps and edge-weight hashmap
$\begin{array}{|l|c|c|}\hline
&amp;\text{Nested Hashmap} &amp; \text{Edge-weight Hashmap}\\\hline 
\text{Store graph} &amp;O(|E|) &amp;O(|E|)\\\hline
\text{Add vertex} &amp;O(1) &amp;O(1)\\\hline
\text{Add edge} &amp;O(1) &amp;O(1)\\\hline
\text{Remove vertex} &amp;O(|V|)&amp;O(|V|)\\\hline
\text{Remove edge} &amp;O(1) &amp;O(1)\\\hline
\text{Check if two vertices are adjacent} &amp;O(1) &amp;O(1)\\\hline
\text{List neighborhood of a vertex }&amp;O(|V|) &amp;?\ O(|E| )\ ?\\\hline
\end{array}$
The entry &quot;$?\ O(|E| )\ ?$&quot; entry on the column of &quot;edge-weight hashmap&quot; means that it is not clear how to list neighborhood of a given vertex $v$ efficiently. $O(|E|)$ refers to the time-complexity of the natural way, which goes over all the edges, keeping only the edges that contain $v$.
So both implementations have the same asymptotic time-complexity and space-complexity for all operations, except for listing the neighborhood of a vertex, arguably the most popular iteration on a graph, for which nested hashmaps are significantly faster. In practice, nested hashmaps should also exhibit better cache-friendliness.
Comparison of programming friendliness
Here are the code that does the basic iterations over a graph represented in variable $g$ using nested hashmap or edge-weight hashmap.
$\begin{array}{|l|l|c|}\hline
&amp;\text{Nested Hashmap} &amp; \text{Edge-weight Hashmap}\\\hline 
\text{Iterate over all vertices} &amp;\text{for v in g:} &amp;???\\\hline
\text{Iterate over the neighborhood of vertex u} &amp;\text{for v in g[u]:} &amp;???\\\hline
\text{Iterate over all edges} &amp;\begin{array}{c}\text{for u in g:}\quad\quad\\\text{ for v in g[u]:}\end{array} &amp;\text{for e in g:}\\\hline
\end{array}$
The &quot;???&quot; entries on the column of &quot;edge-weight hashmap&quot; means that it seems rather clumsy to write that piece of code in Python or other programming languages, assuming their generally-available implementations of hashmap.
Nested hashmaps are far more programmer-friendly than edge-weight hashmap.
Summary
Although the time-complexity of the most basic operations using edge-weight hashmap are very good, it does not support the basic iterations well. It should be replaced by nested hashmaps in general.
Exercises
Exercise 1. Verify that this answer is applicable for weighted directed graph after slight adaptation. Verify that this answer is applicable for (unweighted) directed or undirected graph as well.
Exercise 2. Compare edge-weight hashmap with adjacent-weight list in detail. An adjacent-weight list for the graph above in Python can be $g=[[], [(2,2), (4,2)],$ $[(1,2), (3,14), (4,5), (5,5)],$ $[(2,14), (5, 34)],$ $[(1,5), (2,5), (5,58)],$ $[(2,4), (3,34), (4,58)]]$, where $g[v]$ is a list of $(u,w)$ pairs for vertex $v=1,2,3,4,5$ (g[0] is ignored since 0 is not a vertex), where $w$ is the weight of edge $(v,u)$.