Why would someone need an in-process reverse proxy? I don't see what an in-process proxy would add that a request routing engine couldn't do. Or is the point that you can now add your reverse proxy configuration as just another project within the same solution?

And you could dynamically and efficiently add/remove web apps and endpoints assuming your entire codebase is in C#.

You can also block the clients for a brief period while you make routing changes, or wait for any other arbitrary event to complete. This is one way to achieve zero-downtime upgrades, even in situations where the service is running as a single binary on a single host.

We use it to proxy request from "modern" part of application moved to .net core to legacy parts of application, that are yet to be converted.

This is a "premiere use case" we've seen people use YARP for.

I was assuming more the latter. Also benefit is you can extend and customize in C#.

You might need to deploy a single executable rather than multiple.

I think it either operates as a traditional (heavily customizable) reverse proxy OR you have a app and forwards x% of your API surface to second tier services.

Imho: no in-procees reverse proxying. That should not make sense.