As wooda20 pointed out, a generic, practical example is probably non-existent. At the high level, the business reason for virtualizing TCP is no different than the reason for virtualizing any other protocol.
The reason Dave answered the question the way he did is because TCP is simply the transport on which the data flows. The typical challenges when using TCP are to locate the start / end of a transaction. Sometimes, this requires a custom delimiter. Chances are the payload content will require custom data protocols (or Opaque) to get the request / response into a format that is consumable in the VSI.
One example:
I had an airline customer that had a legacy client server application circa 2000 that communicated with a mainframe application over TCP. The payloads were very specific to the mainframe application. CA was able to virtualize the TCP transactions. The technical architecture of the service supported custom delimiters, parsing of the request / response payload to get usable VSI arguments, and EBCDIC to ASCII data conversion and back. The business outcome was the opportunity for the airline to save thousands of dollars in mainframe compute costs using the virtualization. In this case, the business outcome (i.e., savings) justified the end game. As an aside, the vendor of the mainframe application reviewed the virtualization and was impressed with what CA accomplished -- considering we had minimal information about the makeup of the transactions.