It's certainly possible to overload a control plan with valid "important" processes. BTW, "important" processes, like routing protocols, STP, etc., should have higher priority. If they are normally (i.e. without bugs) consuming much CPU, though, your network design might need review. (For example, there's a reason OSPF supports areas of different types, or why there's "dampening" features, or why there are different "flavors" of STP, such as MST, which avoids PVSTP issues with lots of VLANs, or STP edge port configuration options [portfast], etc., etc.)
As to ping, responding to ping is usually considered a low priority task. I.e. it's not unusual to see high max values when you ping a "busy" Cisco network device. Ping is a very basic "it's alive" protocol, its latency measurements shouldn't be expected to be highly accurate. (NB: if you're looking for accurate network latency, you need an application designed for that. For example, Cisco's IP SLA responder works to improve latency measurement over ordinary ping. [NB: a super accurate latency application would place at risk other network device control plane functions.])
