From Palo Alto : round-trip min/avg/max/stddev = 183.514/184.035/184.898/0.466 ms
From Amsterdam : round-trip min/avg/max = 36/37/39 ms
From London : round-trip min/avg/max = 48/48/50 ms
Obviously this can vary quite a bit depending on what peering you have at your disposal.
For reference, from Palo Alto to London: round-trip min/avg/max/stddev = 156.236/156.921/158.271/0.834 ms
For latency, I would choose NY/NJ or similar if you really want one location to serve both EU and US; Though this isn't ideal, it does lower the latency to West Coast US quite a bit.
From San Jose to Newark : min/avg/max/stddev = 73.462/73.547/73.660/0.078 ms
From London to Newark : min/avg/max/stddev = 72.836/74.323/75.600/1.200 ms
The submarine cable map shows one cable going west to greenland and then Canada, one that goes to northern England, and two to Denmark. The Canadian landing isn't very close to any other transatlantic cables, so it may not be very well connected (land connectivity is much harder to map though).
Anyway, making location decisions based on assuming internet distance is similar to physical distance is kind of silly. There are many physically adjacent countries that don't have direct interconnects, it's pretty common for traffic to exchange through somewhere much farther away than the ultimate destination: many south american countries exchange traffic in Miami.
1. I would be interested to find out if being geographically between San Francisco and Amsterdam is actually good for latency.
2. I think the usual solution to having customers in the US and Europe and wanting to keep latency down, is to setup servers in the US and Europe. So, this strikes me as an odd justification of the decision.