> What does @ mean here? If there's some meaning, the next question is, why doc for staticmethod()
> (and classmethod() in the same page) does not have it?
@ means that the function is meant to be used as a decorator (the markup looks like the actual code).
staticmethod and classmethod are older than the decorator syntax, which is older than the special sphinx markup for decorators (they used to just use the function markup).
For unittest.mock.patch, its result can be used as a decorator or as a context manager, so the current markup (no @) makes sense.
If you want to update staticmethod and classmethod to use the decorator markup, please send a pull request! (more info in the devguide)

Use of classmethod and staticmethod decorators as functions is still a valid use case. I think the old signatures should be kept. It should be possible to document both uses in same place:
.. function:: classmethod(function)
.. decorator:: classmethod
Documentation body.

I think existing uses of the decorator markup rely on the reader’s understanding that it’s syntactic sugar for a call and an assignment, and they don’t have decorator+function markup. The PRs for this ticket follow that.
That said, staticmethod as a non-decorator has an important use case for function injection in tests (using self.func in TestCase classes that work with a C module and an equivalent Python version). Maybe this deserves an extra example?

> That said, staticmethod as a non-decorator has an important use case for
> function injection in tests (using self.func in TestCase classes that work with
> a C module and an equivalent Python version). Maybe this deserves an extra
> example?
Yes, that would be nice.