Possibly the issue is, we call traffic being transported though the device, or transiting the device, "data plane" traffic (I suspect you know that). Other traffic, such as your noted "control plane" and "management plane" are, I believe, often lumped together as "control plane". The latter is done, for the purposes of security, i.e. "data plane" traffic, generally, doesn't have a path of attack into the system.
CoPPP is a method to limit the impact of simple DoS service attacks for entry points supporting the control, and management, planes. Of course, good security practices also protect those two planes, when possible, with totally blocked access too.
The latter statement, I believe, answers your question "Should I think of it as a way to avoid attaching service-policies to interfaces and instead through a virtual pipe that handles all the aforementioned types of traffic before it reaches or after it reaches an interface?" as no. I.e. For security, we use whatever tools seem most appropriate, including in combinations, as early as possible.
CoPPP is a bit of a "Johnny-come-lately", which helps secure our systems from entry points we cannot fully block by limiting volume of traffic to "normal" limits.
Laugh - way back when CoPPP was really new, and not as refined as current implementations, I tried in on one of our main core devices. Worked fine, until the day another engineer tried to FTP a new IOS image to the device, which "crawled!!!". Device was fine, including normal forwarding of production traffic, but it was interesting how CoPPP could easily impact a legitimate function. (I don't recall that CoPPP implementation having a way to allow a full speed FTP copy to device without setting its policed limits to a much higher rate or deactivation of it. Recall we chose to deactivate CoPPP for the duration of the FTP copy, and then reactivate.)
