For starters, WebPageTest uses a traffic-shaped connection to behave more like a consumer Internet connection. In the case of your test with a “Cable” connection that means 28ms RTT added to the link. Looking at the actual socket connect time it looks like it’s ~44ms RTT to the server (including the 28ms from the cable profile).
There are at least 4 round trips to request the HTML (DNS, socket connect, TLS negotiation and the request itself) which would take ~180ms under optimal conditions (the TLS negotiation took 77ms and the server response to the HTTP request took 124ms so there were additional delays).
Usually we see things the other way where pingdom is much faster because there is no traffic-shaping on their connection.
My guess is that there is some protection filtering in the path on your server that is rate-limiting pingdom (either by IP address or because of the connection itself). I’m not sure what browser engine they are using right now but last I heard it was something like Chrome 38 which didn’t support HTTP/2 and uses older TLS ciphers. It’s possible that is causing it to go down a slow path of some kind.
It could also be that the server has variable performance and the pingdom test hit it when all of the caches were cold but it looks to be consistently slow in pingdom and consistently fast in WebPageTest so I don’t think that’s it.
WebPageTest runs the current stable browsers and the results look consistent so I’m pretty confident that teh site itself is responding quickly. If you want to be sure you can add response timing to the access logs on the server or add something like Google Analytics which will report performance metrics from actual usage.