The problem is: due to the need to mix and align with bitmap graphics, web design is most convenient when specifying font sizes in pixels (except for simple pages, like HN and such, fluid designs cannot cover most cases in a mainstream enough fashion).
So, given that, he had to mention a specific pixel setting. But he took into account most common DPIs. For the majority of users they do not vary that much, around 100-120 dpi.
(Btw, have you read the article? He is aware of that, and he even gives examples of 16px in different DPI screens).
Display PostScript - circa 1987 (thanks, Steve Jobs).
I know there isn't a good current alternative in the web world, but shouldn't it be a goal to not have to specify pixels anymore? Obviously mobile browsers already largely ignore/change pixel font sizes.
I understand the difference between pragmatism and dreaming.
In the short term, that pragmatism should include web devs not trying to lay everything out pixel-perfect so it breaks if the user hits "zoom". The diversity of screen sizes and browsers and DPIs is greater than it has ever been, and will only increase.
A realistic strategy today is to assume a typical desktop monitor by default, since not all popular desktop browsers implement media queries to a useful extent. Then you can add specific CSS sections for hardware with very different parameters, such as screens on mobile devices. Usually being both newer and more in need, mobile OSes and the browsers running on them typically support media queries better, so while not always ideal, this approach works fairly well in practice.
Maybe for copy text it's ok, but not for other page elements, ones that we want to align in a specific way to bitmap images, no.
The page-zoom style resizing is our best bet --it's the "resolution independent" way to have your pixels and eat them too.
Now, if we could provide bitmap assets that could be zoomed in the same way, instead of just showing bigger but more pixelated (as we can in application icons in OS X), we would be done.
Yes, you could provide multiple bitmaps in a website now, but in a convoluted way (with some custom javascript checking for resize events etc). In the icons case, it happens automatically.
As for SVG, client rendering time would be insignificant for most case (for a desktop machine at least, they have CPU to spare). But currently used IE version (> 6) for one don't support SVG. And the main problem are bitmap assets such as photographs. Those cannot be done as vectors.
The difference in terminology is subtle to look at, but huge in practice.