If there wasn't an index present, then you would be correct: it would require a NodeByLabelScan through :Article nodes and property filtering to find the ones that have an id that are in the parameter list.
But if an index is present, the planner can use the list to do an index lookup for the exact :Article nodes with ids in the parameter list, no need for filtering.
You can do an EXPLAIN to see the differences in the query plan yourself, just run it with an index present and without.
Typically for fast lookups, b-tree type indexes are used which are log(n). That scales much better across larger sets of data than with a hash, which is why you typically won't see databases using hashtables to back their indexes. Additionally, it allows us to maintain ordering (can't do that with a straight hashmap), which is needed for range querieres and index-backed ordering, which can be very valuable for some queries.
There are some StackOverflow answers that can go into greater detail in the tree-vs-hashtable question for database index implementation.
All that said...it would be really neat to work with a local hashmap structure within Cypher, not as the implementation of an index, but to assist with quick local mappings. We can do this to a degree with Cypher map structures, but we typically need map functions from APOC Procedures to create them:
These can only use string keys, however, not integers or nodes. This won't be useful for the query we've discussed here, index lookup will take care of things nicely, but it may be useful in other cases.