There are a lot of comparisons like "REST vs smth" (eg vs Kafka, vs JSON-RPC), but I also see many similarities between JSON-RPC and JSON Patch – both of them specify operation/method, values/parameters, and allow to perform batch requests. The only difference I see is that JSON-RPC also describes response format with IDs and errors, so it looks more mature. But maybe they just have different pros&cons, different appropriate use cases?
JSON-RPC (2.0) is indeed mostly mentioned as a REST alternative. (A look at the more general discussion, REST vs SOAP vs RPC might be due but this is a rabbit hole, seriously. Part of the problem is, people talking about different RESTs and RPCs and confuse them.) Historically, RPC systems often suffered from confounded dependences related to schema requirements, custom serializations, protocol restrictions, and complex RPC/function mappings. JSON-RPC tries to entangle dependencies, it does not want to be everything RPC for everybody but to stay relatively narrow in scope. It supports a small(er) set of commands, and is more opinionated on how to implement it. Nonetheless, it's a complete package, highly flexible, and used for complex APIs that struggle to map all operations to HTTP verbs. Newer capabilities like events, notifications, and batch actions make JSON-RPC very versatile and a good choice for all kinds of projects; the additions are especially useful for action-based microservices.
JSON-Patch (RFC6902), arguably, tries to solve a single common problem of APIs, i.e. partial updates. Instead of PUTting or POSTing (potentially heavyweight) changes to a (historically) growing URL space, using query params to carry the semantics, or introducing other complexities, JSON Patch offers an atomic update request that patches your JSON using a series of "add", "remove", "replace", "move" and "copy" operations. To quote one of the authors of the JSON Patch RFC, Mark Nottingham (IETF):
This has a bunch of advantages. Since it’s a generic format, you can write server- and client-side code once, and share it among a number of applications. You can do QA once, and make sure you get it right. Furthermore, your API will become less complex, because it has less URI conventions, leading to more flexibility and making it easier to approach for new developers. Using this approach will also make caches operate more correctly; since modifications to a resource will “travel” through its URL, rather than some other one, the right stored responses will get invalidated.
Similar things can be said about JSON Merge Patch (RFC7396, which can be used for the same purpose but works more like a diff/patch that simply contains the changes instead of using mutating operations. In this respect, JSON Merge Patch is simpler but more limited than JSON Patch, e.g. you cannot set a key to null (since null means remove), merging only works with objects {..}, arrays [..] can only be replaced as a whole, and merging never fails, could cause side-effects and is therefore not transactional. This renders Merge Patch (overly) simplistic and impractical for certain real-world applications. There are more related projects named like JSON-Diffpatch, etc that take similar approaches.
In general, all of them have advantages and disadvantages, and none of them will fit everybody's use-cases. It really depends on what problems you want to solve with your APIs. JSON-RPC is arguably more versatile and mature, however, JSON-Patch is also a sound choice, especially if you control both sides of the communication.