For Superset we use SQLAlchemy and much of the connectivity goes through the DBAPI Python abstraction, and I believe most of the drivers are using native implementations.
And there you have it, "turtles all the way down". SQLAlchemy sitting on DBAPI, where you can get to databases primarily through: 1) ODBC/JDBC, 2) ADO or 3) native Python database drivers contributed by the community that speak the wire protocol of the database (usually wire protocols that are open source or openly documented).
These abstractions most programming languages have make the problem mostly go away for developers.
However, sometimes you'll find (as is sometimes the case with SQL Server, for example) that the fastest or most complete/stable database driver is a specific one that is not quite 100% (but could be 99.9995% supported) completely supported. For example, Python gets to SQL Server via ADO (only on Windows) or some driver (usually ODBC) that talks TDS protocol - often FreeTDS (open wire protocol compatible with SQL Server).
We are definitely in a better state today with regards to programming language/framework support for interfaces to databases, but I think the historical context of the original "generic database interface standards" (JDBC/ODBC) is important to understand to know how we got to where we are, and why sometimes people struggle to ask "what BI tool is the first to come to mind on Microsoft/Windows stack"? Don't get me wrong, plenty of Microsoft/Windows supported BI tools exist, and cross platform abstractions like those in Python make it so OS matters much less (but still matters).
