Sure, I'd be happy to write down a few thoughts. I spend a fair bit of time with speed test tools for all my clients, and I've gotten my hands dirty optimizing quite a few different sites at this point. I just got done with a wordpress function setting the custom responsive images 'sizes' attribute based on css class information for the different kinds of images in a client's theme. Wordpress' default responsive image setup is great compared to what it used to be, but there's still a lot of room before it's as robust as I'd like to see it. Good thing I know how to code I guess.
1 - There's two aspects of 'results' here. First is the practical: page load speed, server requests, and page size are the most important in that category. The results aren't just different in each of those three sites, they're different even for multiple refreshes on one site. Page size and requests are always going to be the same, but the speed can vary by as much as 300% depending on your test location and luck of the draw. When testing site load speed, I usually use two sites (pingdom and gtmetrix) and I run both a couple times and take the average.
There's a lot of reasons page load speed can fluctuate so much. Some servers have a variable amount of load, one page load request might come when it's idling and you'll get your requests processed and sent back quickly. Other times, there might be a lot of traffic besides you, and you have to wait your turn. In the waterfall chart, a high 'time to first bite' or a lot of waiting for individual elements can imply you need to switch to a better server. Another reason different sites have different results, is the test location. Larger geographic distances means longer latency. That's why CDNs can be a good idea, for size heavy page elements, it figures out the closest, most available server to use to send you the data you're requesting. For the first site you posted (the mobile test site), it artificially slows down the transfer speed to mimic what users will experience on a 3G network. You'll obviously see much slower times with a slower internet connection.
It's worth noting too, for most of us here, we've got local sites with local visitors. Don't test a site in Dallas with a test server in Canada and expect to get the most useful information. Most of these page load speed sites will let you pick your test location, pick one close to the client.
The second aspect of all these tests, is the 'score', usually calculated by looking at which best practices you're screwing up. I'm sure that Google looks at your score to an extent when deciding your ranking, but I'm also sure Google's with me when I say that practical end results are more important than best practices. It's a waste of time to shoot for 100 on Google's own speed test, much less someone else's. I use those score charts mostly as a guide to decide where to spend my optimization time when improving a client's site. It's just one piece of information though. Google can tell you what to shrink and such, but it can't tell you the site's designer installed a ton of garbage plugins that don't actually help site functionality all that much. Sometimes the whole job even is just culling out those worthless plugins and optimizing the images.
2 - Many of Google's recommendations are very important, but some of them need a bit of filtering. If you're working with a client that almost exclusively has one-time visitors for example, it won't matter so much if you enable browser caching or not (though there's no reason not to of course, just don't expect it to help anyone much). Render blocking css or javascript isn't ideal, but if it's required for the function of the page above the fold, there's worse things than leaving it in place. Optimizing images and minifying css/javascript files is all well and good, but your bottleneck could very well be the number of server requests, not the sizes of the individual elements that make up the page. In that case you're better off consolidating external files, and disabling unnecessary plugins and page elements instead of shrinking all those elements individually.
3 - You should believe what works. When you get more comfortable reading the waterfall graph, it usually gives you the best clues on where to focus. Beyond that, you can believe that a slow page load speed leads to worse client experience, and that if it's bad enough (or if you're in a more demanding industry) a slow website will directly affect your bottom line.
4- I shoot for under 2s average. Some clients come to me with pretty bloated sites, or sites made with a framework I can't easily modify (Squarespace, etc). I work with a lot of photographers too, image and design heavy pages are just going to be a little harder to get working quickly, especially if you don't want to employ some kind of lazy load. It's also worth looking at Google Analytics to see what percentage of visitor traffic is coming through mobile. If it's over 50% mobile, I'll pay much more attention to mobile load speed than I will if it's just 10%. Every industry has different customer expectations and behavior, and every client has different technical restrictions on their website, so you do what you can.
