in short: the problem is that a ScriptableRenderPass in URP currently doesn’t match an “hardware” RenderPass (think of it at the API level, like Vulkan RenderPass, Metal Encoder, etc). The problem with that is that we are unable to fully optimize and merge passes at the URP level when you start having multiple RT switches inside Execute code, so the downside of this is much less opportunity for URP to optimize the frame. Basically we can never make the assumption that a ScriptableRenderPass will end up being an “actual” pass in the backend.
In 23.2 we are moving to the RenderGraph API, this is already used by HDRP so it also gets us in a better place in terms of having both pipelines using the same API. Thanks to the new API, every time you will have to switch an RT you will have to create a new RenderGraph pass. This makes URP’s life much easier in terms of having the guarantee that every pass will never change bound attachments, resulting in much better end performance, and also clearer API.
You can have a look at the HDRP code base to have a preview of the API, even though for any proper deep dive I suggest to wait for us to release it in URP. By that time we’ll provide more info and upgrade guides