It's not just implementation, but also semantics.
A vector is an ordered, O(1) access/modification, structure.
A hashtable is (usually) a non-ordered, amortized O(1) access/modification structure. The implementation details don't matter, but these characteristics do, since they are important to reason about your algorithms.
(Edit: You may think you can treat integer-indexed hashtables as vectors. Suppose you have a 'map->list' operation that applies fn to given aggregate type and returns the list of results. The semantics of (map->list fn a-list a-vector) is obvious. (map->list fn a-list a-hashtable) is not so obvious, and eventually you'll end up different map functions for different purpose. So it's a trade off---fewer data types and more specialized functions, or more data types and fewer
generic functions. Of course where is the optimal point is arguable.)
Can the compilers be smart enough to figure out the data structure that minimize your algorithm's computation complexity? I don't know. Eventually, maybe, but at that time algorithms will be described in very abstract level, I guess.
Of course you can merge these two characteristics (adding order info to hashtables, which I believe Ruby just did recently). It's a trade off, affecting constant factor.
