In my experience writing collision detection, mesh-based collision (triangles versus other triangles) are the most expensive form of collision in physics engines (PhysX, Havok). Unity uses PhysX internally, so this is no different. Because each computer and platform perform differently, exact numbers cannot be provided, but generally speaking the relative costs of collision detection of types are in the following order, from most expensive to least: triangle mesh, convex hull, box, capsule, sphere, plane, point.
Triangle meshes have the least-helpful characteristics for writing efficient collision detection. As a mesh, they don't guarantee convexivity, are not solid, and cannot be described implicitly through an equation. As a result, any detection is performed with each triangle individually.
To expand on triangle mesh collisions, and without direct knowledge of the source code, I would think Unity does collision detection against triangle mesh in the following way: a spatial data structure wraps the triangles. Likely a KD-tree, bounding volume hierarchy (BVH) or some other form of hierarchical structure. This accelerates queries between primitives and the mesh, yielding a list of candidate triangles for what is called narrow-phase collision algorithm. Then primitive-v-triangle tests are performed. For spheres, the basic sphere-v-triangle test calculates the distance of point from triangle testing if the distance is less than the radius of the sphere. More complicated primitives against the triangle use the GJK algorithm, or SAT algorithm against the triangle.
To address the high cost of triangle meshes, most games that require high fidelity collision detection with characters resort to using a combination of primitives to approximate the character - spheres, capsules or convex hulls bound to the joints of the skeleton hierarchy. The actual number of shapes used to represent the character are determined by requirements and the hardware the platform running on.
So to answer your question, I don't think there is always an objective answer to your question about 'exactly how inefficient a mesh collider is...'. But a handful of simple primitives is always faster then a deforming mesh geometry.