I don't think the author is suggesting that details don't matter. Rather, he is suggesting that on a first pass through material, it is often better to focus on learning the material on a conceptual level (where is this material taking me? What does this theorem really tell me?) rather than focusing on the mechanical details of the derivations and proofs. To a certain extent, this is already built into the curriculum: freshman and sophomore mathematics coursework tends to focus on concepts and computation, while junior and senior coursework chases after the fundamental reasons why the theory works. Consider, for example, the relationship between Calculus I (freshman course) and Intro to Real Analysis (sometimes called Advanced Calculus, typically in the senior year). These courses cover very similar material, but the mathematical maturity required for Real Analysis course is significantly higher. I believe the author is suggesting that students spend more time on understanding the "why" and less time on "how". You can go back and figure out the "how" much quicker a little later on. "How" is nevertheless important, because ultimately you need to learn how to prove your own results.
The other important point is that the author's intended audience are individuals who are determined to master mathematics at a deep level, the sort who are determined to crank through all the details. The message makes much less sense outside of the intended audience.
Note that this is a United States patent case. Under US patent law (unlike international patent law), patent rights are assigned by first to invent, not first to file. This means the case depends on how long Nintendo and ThinkOptic were working on the devices before filing. This makes for really messy patent fights. I'm really surprised that Nintendo wouldn't have previous patents related to this technology. Then again, they probably do, but those patents aren't mentioned in the article, which is written from the ThinkOptic perspective without a response from Nintendo.
I've used both systems for small, medium, and large documents as well. For documents that are written by large numbers of authors in short amounts of time (like grant proposals), I like Word with Track Changes. I find the visual display of changes in the formatted document focuses attention and speeds up the writing process. I'm fine with non-WYSIWYG editing in general, but the visualization of changes is just really effective.
I know how to return clicks from xdvi and yap to an editor. But it's the coauthors' edits that I'm interested in, not just finding my place in the source file or identifying who wrote a particular line.
I've used versioning systems with latex documents as a single author as well as with coauthors. It worked great as a way to keep a centrally located authoritative version of the document. One thing I didn't like was that versioning systems often pay attention to whitespace, so trivial changes in the line wraps would be reported as large changes in the document. (This was with CVS. Perhaps newer systems understand text better.)
With latex documents for which someone else is the primary author, I often end up writing comments on a printout, scanning, and returning. This generally ends up being a better use of my time than trying to teach a coauthor (often not a programmer) about versioning systems.
If Chrome is suddently twice as fast on Google websites then all other browsers, then gives the combination of Chrome+Google websites a huge advantage.
Because the big bottleneck on the web is the time spent waiting for search results?
"Would I turn on the gas if my pal Mugsy were in there?" "You might, rabbit, you might!" -- Looney Tunes, Bugs and Thugs (1954, Friz Freleng)