I've generally faced far, far, more maintenance problems associated with pure interfaces than ABCs, even ABCs used with multiple inheritance. YMMV -- dunno, maybe our team just used them inadequately.
That said, if we use a real world analogy, how much use is there for pure interfaces completely devoid of functionality and state? If I use USB as an example, that's a reasonably stable interface (I think we're at USB 3.2 now, but it has also maintained backwards compatibility).
Yet it's not a stateless interface. It's not devoid of functionality. It's more like an abstract base class than a pure interface. It's actually closer to a concrete class with very specific functional and state requirements, with the only abstraction being what plugs into the port being the only substitutable part.
Otherwise it would just be a "hole" in your computer with a standardized form factor and much looser functional requirements which wouldn't do anything on its own until every manufacturer came up with their own hardware to make that hole do something, at which point it becomes a much weaker standard and nothing more than a "hole" and a specification of what it should do, but no central provision for how to do it. Meanwhile we might end up with 200 different ways to do it after all hardware manufacturers try to come up with their own ways to attach functionality and state to that "hole".
And at that point we might have certain manufacturers that introduce different problems over others. If we need to update the specification we might have 200 different concrete USB port implementations with totally different ways of tackling the specification having to be updated and tested. Some manufacturers might develop de facto standard implementations they share amongst themselves (your analogical base class implementing that interface), but not all. Some versions might be slower than others. Some might have better throughput but worse latency or vice versa. Some might use more battery power than others. Some might flake out and not work with all hardware that's supposed to work with USB ports. Some might require a nuclear reactor to be attached to operate which has a tendency to give its users radiation poisoning.
And that's what I've found, personally, with pure interfaces. There might be some cases where they make sense, like just to model the form factor of a motherboard against a CPU case. Form factor analogies are, indeed, pretty much stateless and devoid of functionality, as with the analogical "hole". But I often consider it a huge mistake for teams to consider that to be somehow superior in all cases, not even close.
To the contrary, I think far more cases would be solved better by ABCs than interfaces if those are the two choices unless your team is so gigantic that it's actually desirable to have the analogical above equivalent of 200 competing USB implementations rather than one central standard to maintain. In a former team I was in, I actually had to fight hard just to loosen up the coding standard to allow ABCs and multiple inheritance, and mainly in response to these maintenance problems described above.