Many of his examples (like "what if we want to change the method to return a float instead of an int?") could be avoided by using a dynamically-typed language.

A dynamically typed language is: A) not always an option, and B) not a solution to the general problem of possible changes to the underlying data representation. Although it may be a perfectly acceptable solution in the simple case you describe.

I cringe at the thought of attempting this by following the author's advice. By having the data stored in one object (which you can call a fancy data structure if you want) and given to a subclass of a ReportGenerator object solved this problem quite elegantly for me.

You cringed, but did you then attempt to imagine how such model might work? In the simplest terms, the controlling code in your model creates (or otherwise obtains) the data object, creates an appropriate ReportGenerator object (based on the desired output format desired), and then passes the data object to the generator object which uses accessors to retrieve the data, formats it appropriately, and produces output somewhere or returns a formatted string (or something unspecified). Even if that doesn't describe your model, let's consider it anyway.

What if I described a model, in simplest terms, in which the controlling code creates an object and asks it to generate an appropriate report (again, based on the desired output desired). Does that sound so awful? The system I imagine here still has ReportGenerator subclasses, but the object's to_html() method (for example) does any necessary transformations on its underlying data representation, instantiates the appropriate generator, and produces the output or a formatted string, or perhaps it takes an IO object and appends itself (and the IO object could point to a file, STDOUT, or a scalar). Should the object require non-trivial changes (to accessors or underlying data representation), I do not need to go beyond the class itself to make these changes.

I hope I wasn't (and am still not) sounding adversarial. That is not my intent. I haven't made up my mind whether the author's methods are sound or not. For myself, I need more than a simple reading of the articles to make that decision (if I want some semblance of intellectual honesty). I'm not prepared to simply brush it aside because of any received dogma about the separation of implementation and display.