Switch – the maximum normal latency for internal gateway switch

Speed of Light:
You are not going beat the speed of light as an interesting academic point. This link works out Stanford to Boston at ~40ms best possible time. When this person did the calculation he decided the internet operates at about "within a factor of two of the speed of light", so there is about ~85ms transfer time.

TCP Window Size:
If you are having transfer speed issues you may need to increase the receiving window tcp size. You might also need to enable window scaling if this is a high bandwidth connection with high latency (Called a "Long Fat Pipe"). So if you are transferring a large file, you need to have a big enough receiving window to fill the pipe without having to wait for window updates. I went into some detail on how to calculate that in my answer Tuning an Elephant.

Geography and Latency:
A failing point of some CDNs (Content Distribtuion Networks) is that they equate latency and geography. Google did a lot of research with their network and found flaws in this, they published the results in the white paper Moving Beyond End-to-End Path Information to Optimize CDN Performance:

First, even though most clients are served by a geographically nearby CDN node, a sizeable fraction of clients experience latencies several tens of milliseconds higher than other clients in the same region. Second, we find that queueing delays often override the benefits of a client interacting with a nearby server.

BGP Peerings:
Also if you start to study BGP (core internet routing protocol) and how ISPs choose peerings, you will find it is often more about finances and politics, so you might not always get the 'best' route to certain geographic locations depending on your ISP. You can look at how your IP is connected to other ISPs (Autonomous Systems) using a looking glass router. You can also use a special whois service:

whois -h v4-peer.whois.cymru.com "69.59.196.212"
PEER_AS | IP               | AS Name
25899   | 69.59.196.212    | LSNET - LS Networks
32869   | 69.59.196.212    | SILVERSTAR-NET - Silver Star Telecom, LLC

It also fun to explore these as peerings with a gui tool like linkrank, it gives you a picture of the internet around you.

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.