I think of a reverse proxy as more of a general architectural pattern - when you have cross-cutting concerns for an application with a relatively broad protocol (HTTP) you can implement them as a networking layer in front of the service(s). Indirection and abstraction are powerful tools in computing.
Common reasons for such a split:
1. Composing several different services into a single internet domain
2. Putting stateless or CPU-heavy workloads onto different infrastructure from long-lived, IO-intensive tasks
3. Variation of the above, allow for multiple server processes in server environments which can't scale up to single multi-threaded processes well (CRuby/CPython)
4. Split security concerns off onto a box which has a much smaller attack surface, such as a box meant to be deployed in a DMZ (examples would be HTTPS termination, authentication and authorization policy enforcement)
5. Caching of responses (this is Varnish's claim to fame)
6. Variation of the above, some CDNs work by hitting an otherwise private server for data, then replicating throughout the network for locality to end-users.
7. Application-specific behavior patching, such as adding new API endpoints or changing the behavior of existing ones
In many of these cases, people use something like NGINX, Apache or a commercial solution like an F5. In other cases (such as application-specific business logic) people will write their own code, perhaps in the future using this Microsoft project as a starting point.