@Dan: this is probably where the excerpt fails slightly, as I’m a huge (and outspoken) proponent of letting content determine where breakpoints are. The chapter this comes from is mainly about sketching; you already know a lot about your content and you’re making *estimates* about what this content will do based on very loose categories of devices or screens or browsers (or even capabilities). You will revise this when you get to a web-based design mockup, but you have to start somewhere, and for many designers, starting in the browser is just too much to ask. I have to give them a break, since I ask them in the book to ditch Photoshop comps.
This process is more like, “Once this gets much wider than a smartphone, one column simply won’t do for this content. I’ll most likely change the layout. How might that look?”
Devices *classes* are groups of similar devices, not specific devices. Since they are just “types” of devices, they are not fixed at all. Device classes could be “devices with very narrow screens”, or even “devices with a camera”. They are NOT, however, iPhone 5 or HTC One. So I tend to disagree with you that device classes are too fixed.
See this sketching as a way of planning for the web’s fluidity. Designers need to accept that fluidity, but sketching what they might want to do at various breakpoints helps them design for it.
In the end (and unfortunately what happens next is not part of the excerpt), the design will take the form of a mockup in the browser, and what happens there will determine where the real breakpoints are. Sure, you don’t know beforehand exactly where a particular major breakpoint will be. Sketching breakpoint designs beforehand, though, does afford you the opportunity to have an idea of what you’d like to do when that breakpoint does occur. In this sense, where breakpoints happen is absolutely in the eye of the creator.