Common examples for useful request parameters would be any framework parameters carrying state and flow control information, component names (Richfaces etc.) but also simple item or product IDs or even just a form name. For header values it could be things like userdatajsf, soapaction or any non-standard client-address information.
I consider this to be fairly important (if not essential) in cases where the URL is simply not sufficient enough to provide a meaningful business context for performance monitoring. In our specific case this would apply to a few highly critical backoffice applications (e.g. not internet-facing).
Losing the URL information in the service screen would be okay if the naming/grouping rules would still allow (partial) URL matching in addition to request parameters, headers etc.