First off Metabase Clojure is on top of Java. So we’re in JDBC not ODBC land.
Second what you’re hinting at has already seen some speculations from the core team it seems:
As I understand it “driver” is a bit of a misnomer. A lot of the Metabase “drivers” actually build on top of JDBC drivers (for databases/sources that has such a thing). So for most it’s more of an adaptation layer that mainly iron out SQL differences and adapt it all to the MBQL abstraction which the Metabase query builder UI is built on. Even most of the SQL drivers inherit base functionality from a base implementation:
It’s all very well covered in this wiki page: https://github.com/metabase/metabase/wiki/Writing-A-Driver
I think the biggest “obstacle” towards just supporting everybody’s pet DB is that for each of them it also comes with a maintenance burden. That’s why the core developers are quite firm when it comes to having test coverage for each new “driver” - and yet still they have to somehow also provision and maintain the test infrastructure for this - potentially for a long time.
You know first hand that even a common and popular JDBC backed DB like mssql have generated quite a lot of 
One IMO potential good way to reduce this burden would be getting in support for one or more Apache Calcite based JDBC drivers (Calcite, Dremio, Drill). With SparkSQL just landed in v0.29.x the road has been paved for this as it’s also Calcite based - Drill almost got in as part of that PR but stumbled). I think (hope?) that could potentially relieve some of the “driver” burden in Metabase land (ElasticSearch, Map-D, CSV/JSON/Excel based files and potentially also ClickHouse) and channel implementation effort for new exciting data sources to a common layer well below Metabase in Java land where implementation effort can be shared. The cost of this of course seen from and end user perspective would be that there’s a bit more moving parts involved in configuration - and upkeep …
Phew 
there, todays rant!