New in Python 3.8:

Some of the benefits of interfaces and protocols are type hinting during the development process using tools built into IDEs and static type analysis for detection of errors before runtime. This way, a static analysis tool can tell you when you check your code if you're trying to access any members that are not defined on an object, instead of only finding out at runtime.

The typing.Protocol class was added to Python 3.8 as a mechanism for "structural subtyping." The power behind this is that it can be used as an implicit base class. That is, any class that has members that match the Protocol's defined members is considered to be a subclass of it for purposes of static type analysis.

The basic example given in PEP 544 shows how this can be used.

Copyfrom typing import Protocol

class SupportsClose(Protocol):
    def close(self) -> None:
        # ...

class Resource:
    # ...
    def close(self) -> None:
        self.file.close()
        self.lock.release()

def close_all(things: Iterable[SupportsClose]) -> None:
    for thing in things:
        thing.close()

file = open('foo.txt')
resource = Resource()
close_all([file, resource])  # OK!
close_all([1])     # Error: 'int' has no 'close' method

Note: The typing-extensions package backports typing.Protocol for Python 3.5+.

After discussing a bit in the question comments and checking a pull request addressing the example of the question I can understand now why the example is correct and where my reasoning was off. Here it goes:

Typical case: checking an instance against a Protocol

Let's expand the example a bit to consider the more common case of checking if an instance of C is an implementation of ProtoA or ProtoB:

c: ProtoA = C()  # OK
c: ProtoB = C()  # Type check error, signature don't match!

So, clearly, and as expected, an instance of C is an implementation of ProtoA because the promise of ProtoA is that any implementation of it will have a method meth that can be called as c.meth(2) (2 can be any other integer in this case), and I can clearly do:

c.meth(2)  # This is correct according to the signature/type hints.

Given case: checking a class against a Protocol

So, what happens in the given example? What happens is that C has a method meth but it's not defined as a class method, so, C.meth has a different signature than c.meth, in fact, C.meth has the signature that is promised by ProtoB, and not by ProtoA, because to use C.meth directly from the class, I need to pass an argument to satisfy self, which has implicit type Any:

# This...
c = C()
c.meth(2)
# ...is equivalent to this.
c = C()
C.meth(c, 2)

# But the promise is fulfilled with anything as first argument
# because there is no explicit type hint for `self` and thus it is
# implicityly typed as `Any`.
C.meth('anything is fine here', 2)  # this is a correct call*

# *although it might result in an error depending on the implementation 
# if the `self` argument had runtime requirements not expressed in the 
# type hint.

So there it is, it had a simple explanation after all.