Intermittent high ping/latency problem
WISP? Meaning Wireless ISP? If so, there's your likely answer. Wireless is unreliable and you're seeing proof of that.
You can't really fix it because your medium (the atmosphere) is really awful for transmitting data. First because air is a hub instead of a switch so you're sharing it with anybody around you and colliding packets, second because CSMA/CA is slower than CSMA/CD, third because wireless is generally half-duplex instead of full duplex, and fourth because there are orders of magnitude higher interference through the air versus copper. [Microwaves, for example, operate at the same wavelength as 802.11b/g... but the microwave operates at about 500-1000 Watts vs your wireless antenna's 100 milliwatts. Microwaves are shielded, but shielding isn't perfect and microwaves aren't regulated by the FCC so it's not illegal if they cause interference.] Plus the fact that you're going through 10+ hops just to get to the Internet. That can't be helping, particularly if there's any NAT or firewalling going on.
As @dbasnett says, the traceroute ping latency to a given host only indicates the state of the entire network in between the interfaces taken as a whole at that point in time. That's why the response times go down sometimes. They're spiky because the network is unreliable. Your pathping looks good because it is running a large number of queries instead of just 3 that tracert is running. So pathping shows you what the network is doing over a period of 325 seconds (by default), and tracert is showing you what 3 packets per hop on the network are doing.
9 times out of 10 trace route results are not an indication of network issues. Traceroute sends ICMP echo request packets to each successive hop between the source and destination, incrementing the TTL by one for each successive hop. The result from each hop are an indication of how THAT hop is responding to ICMP traffic, it is not an indication of the quality of the path through and beyond that hop. A routers job is to forward traffic and as such, many are programmed to ignore, drop, or give low priority to ICMP traffic directed to themselves. The fact that hops 14, 19, and 21 have very good response times are indicators that there's nothing wrong with the path. If there were a problem at hop 12 (as you highlighted) or at any other hop that was affecting the path then you would see a problem at every successive hop and you would see each hop worse than the one before. Only when you see those types of results in traceroute should you suspect a path issue. Hop 21 is the destination and, with a 59ms response time, is telling you that the path between the source and the destination is fine. The key to analyzing a path issue is to analyze it's performance while real data is transiting it, which can't be done unless you have a packet sniffer/network monitor at each hop and have access to memory, CPU, and throughput counters on each network node (routers and switches) in the path from source to destination.
Rather than trying to figure out why you have performance problems based on a tracert of the path, you should concentrate on the actual TCP session between the source and destination and look at the response time (latency) and any packet loss between these two endpoints.
Trace route, as it's name implies, is a tool for discovering the path between two endpoints, it is not a tool for analyzing the quality of that path.
I have to agree with joeqwerty, ICMP long ago stopped being a reliable measure of performance, latency, or throughput. This would be especially true for routes with a lot of hops over unknown networks.
A more realistic test would be one with the protocol(s) that you are using. For example if it were http, you could setup a Wireshark network packet capture. Filter on the conversation with the specified host, and use Wireshark's Statistics > TCP Stream Graph > Round Trip Time Graph. This test is more accurate if you perform the capture for at least several minutes.
Another interesting option is PingPlotter Standard (not free, but is feature-complete for 30 days). This provides a very nice ability for protocol-specific throughput testing by specifying the port number, and has graphs of round-trip time and can be saved and loaded.