I believe they are suggesting that the above comment "Short of a oscilloscope hiding in the computer you use" might not be so far fetched. The hardware needed to do the type of analysis used for this attack has been around a long time and is presumably very cheap at scale. So if for example a nation/company that has control over the manufacture of a large number of USB controllers decided they wanted to be able to do this kind of power analysis on all USB devices plugged into their controllers they could do so easily.
Esentially adding a micro controller with an Analog to Digital converter that can watch the power pin inside the USB controller/port itself would be relatively simple and cheap.
It would appear in this specific case, you would still need a qualified professional to insert the drug soaked 'sponge' and cover the hole. So if this makes it to market it would just be the latest and greatest new tool for dentists to repair tooth decay.
As far as lobbyists blocking innovation to protect their industries 'status quo.' Yes I imagine it happens quite a bit. For example there is a strong lobby to keep tax forms and processes complicated and unfriendly to normal people so that companies whose bread and butter is helping you fill out your taxes each year can stay in business.
20% is very low. We use machine transcription at work, and although the per-word confidence of machine algorithms varies wildly given the quality of the audio and the speaker's mannerisms. It can easily get into the 80% range with good audio, especially televised audio where people are close to microphones and there is not a lot of non-speech noise.
The team at Kadira is great at diving into technical subjects and making fun and easy to follow learning materials. I loved Bullet Proof Meteor, I'm looking forward to learning GrapgQL through this new course.
To answer your first question, there are a number of attractive advantages to using Meteor over say socket.io or autobahn on top of Node. One major one would be a consistent API for accessing your data on the Client and Server. I would argue that using Javascript on both backend and frontend with Node boosts a developer's productivity by reducing language/context switching. In the same vein accessing data using the Mongo query api on both backend and front end with Meteor's MiniMongo improves development. Also Meteor comes with built-in latency compensation when using either RPCs (with stubs on the client) or Minimongo operations. Latency compensation is a non-trivial problem which would need to be implemented by the developer when using something like socket.io. You also gain access to a growing list of great packages that implement things like user accounts which you would otherwise need to write yourself or wire together from various projects.
As for your second question. There are certainty use cases where MongoDB isn't appropriate, and support for other databases is on Meteor's roadmap. For now there are some community created packages for interfacing directly with SQL databases in place of MongoDB, but there are a number of issues with them. You could also pipe data in and out of an SQL database inside RPCs, however the data would not be updated in 'real-time' to clients. I anticipate SQL databases will get some good support options in time.