Anecdotally, at least, this "impedance mismatch" appears to be peculiar to situations where one wishes to push relations into an object idiom.
In C most database APIs tend to expose result sets as multi-dimensional arrays, rather than as structs. Consequently, one is simply accessing the data in the same format as it exists in the table(s) in the database -- it's inconsequential that it now exists as a local copy of the data, rather than "in the database".
Most functional RDBMS libraries expose database rows as record types, which correspond at a reasonably deep level to database rows almost perfectly. There is no "impedance mismatch" in this situation.
The Wikipedia article on the subject appears to speculate as to some of the reasons why the object paradigm is particularly susceptible to this mismatch.
My belief is that it essentially hinges on the fact that you are always building a secondary representation of the data (i.e. overlaying "objects"). In most imperative or (non-object) functional languages, one is less likely to build such a large, semantically irrelevant secondary representation of your data. If one is going to build a secondary representation in that world, it is more likely to be an abstraction of some kind. This corresponds to a basic (unsubstantiated) belief of mine that the OOP paradigm is basically the proverbial hammer that makes every problem look like a nail.