It might not always be the decision of the 'respectable website' to monetize traffic in this manner.
"Not remotely exploitable."
The security industry would define this as a remote exploit as it does not require physical access to any of the devices nor does it require the attacker to be logged into the target devices. While the attack would result in decrypting any clear text being sent over wifi, the saving grace is that an increasing amount of traffic is sent via HTTPS or SSL, which would provide an additional barrier to an attacker seeing login credentials for remote websites, etc.
The most dramatic concern here is that non-HTTPS traffic is prone to injection of malware and exploitation of vulnerabilities on the client devices. Even if a user doesn't browse a sketchy website, suddenly a site like slashdot.org might seem to send code to a user's phone or laptop that could perform a remote code exploit.
As 140Mandak suggests, it would be trivial to assemble a cheap box (think raspberry pi 3) that sits at a public wifi location and automatically attempts to hack all older Android phones that connect to the network.
"John McAfee said.."
The best use of my time and attention is to keep walking down the sidewalk when I hear the delusional rantings of a person probably off his or her meds. No eye contact. Just keep walking.
Any professional outfit will test a new release (in-house or commercial product) thoroughly before letting it get anywhere close to an environment where their business is at stake. This process can take anywhere from a day or two to several months, depending on the complexity of the operation, the scope of the changes, HOW MANY (developers note: not if any) bugs are found and whether any alterations to working practices have to be introduced.
I wanted to chime in with a tangible anecdote to support your observations here.
I work for an enterprise software company. One of our customers is a large credit card company. After our company was five years old, that credit card company still staffed more implementers / developers / testers dedicated to deploying our product throughout their organization than we staffed developers in our entire engineering team.
Talk about a ripple effect....
If at first you don't succeed, you are running about average.