I personally didn't find much value in it. It was mostly done to satisfy the certification requirements.
Burp as a tool doesn't seem well suited to testing web services vulnerabilities. It is more focused on the web sites/applicaitons.
In my case there was a medium level warning about a possible XML injection risk as the web service was sending back a
]]>> that was injected into the request. But what does that really mean for the web service? The web service wasn't actually processing the request, instead it was sending back a response that the request was badly formed and the ]]>> was the issue. Not much of an injection risk as the response needs to pass through the wsdl2apex generated classes first. If there was a vulnerability it would be in wsdl2apex.
I think the only other thing of note was an email address that intentionally appears in some of the responses. Again, a non issue.
What did actually happen with the app submission was that the Salesforce certification team somehow found a web application that is connected with the same web service and was provided by the web service provider.
My interaction was only with the web service from Salesforce, but there was a separate web front end from the web service provider that worked with the same data. I didn't have anything to do with the separate web application so didn't BURP test it or include it in the submission.
They tested the web application and found issues there which caused the certification to fail initially. Fair enough that they found it I guess.
You might find yourself in a similar situation with the web service data also being surfaced in a web application. In that case you will want to run BURP over that web application. It will be a lot more informative there.