In general, I try to virtualise directly behind whatever system is in-scope for the test phase that I'm in. I don't want to require any downstream systems in my application stack that I'm not specifically testing. In that way, I can be sure that any defects I find are either in the application I'm testing, or are expected failures from the virtual service.
So, if I'm supporting component integration testing, I want to virtualise the endpoint that my object calls, even if that endpoint is another object in my container.
If I'm supporting system testing, I want to virtualise the endpoints that my SUT uses. This might be directly behind the SUT, or it might be in the ESB layer, depending on the architecture.
If I'm supporting system integration testing, I want to start with my system testing endpoints so I can start SIT as soon as something is available. As soon as a "nearest neighbour" system is available, I want to remove the virtual services which were supporting that functionality, and add virtual services behind the next system. This enables iterative SIT, leading to more controlled defect capture and much faster time-to-fix.
It also depends on whether we're using pace-layered application strategies, whether we're in an agile framework, what V-Model processes we're using, what devops toolchain applications are in-use, the risk profile of the project, and many other company-specific SDLC decisions.
So, in conclusion, advantages and disadvantages are dependent on the make-up of the project in which we're implementing service virtualisation.
The only common factor between projects might be "we use third party services", in which case a default answer might be "virtualise at the endpoint where you interact with the third party, and make sure you add all their boundary and error conditions as well as replicating the state model, so you have something that emulates the behaviour you need to test. In practice, it's likely to be different for each user of a third-party system (lots of ISO-8583 formats, different authorisation & authentication options, business rules restricting data scenarios, country-specific rules, API customisations, etc), so the approach might be common but it's unlikely that the virtual services themselves can be common. Don't forget to add API tests to your service virtualization effort, so you can regularly validate your API assumptions with a real instance of the third-party API, and you'll be able to see when they change it without telling you.