I think his first example is a little contrived. If you've really gotten yourself into that pickle, you probably didn't think hard enough about the problem in the first place.
The "largerThan" and "addTo" methods make sense because rather than carry two values & imposing some semantics outside the class on the separate values, he's defining the operations on value / currency pair through the class operations. And that's a good thing, because the meaning of "largerThan" or "addTo" are encapsulated in the class. Which is (probably) better than leaving the definition (and possible misuse) to the client.
But an alternate approach would be to express all money values in some canonical currency, do all your operations in that common currency, and then convert it to the desired currency at the last minute.
The part where he dispenses with the getter in favor of a write to method is ... something. One could argue that introduces a dependency on the Writer interface rather than allowing the client to get the value and do with it what it wants.
I've done that before, but not as a general practice.
For example, if you were going to serialize Money to JSON, would you introduce a "toJSON" method that accepts a "serializer" object? Now that class has another dependency & an more semantics to manage. There's potential for blowing up the interface with all the different integration points.
...e.g. to forge on, how would you save a Money to a database as a part of some transaction?
So he's making an interesting point, and I think his example of rolling up logical operations into the class is a good one. But the idea of completely dispensing with getters is an interesting refactoring, but not one that I commonly see.
I think the core idea here is that he has an example where the operations are spread across 4 classes: Money, Currency, CurrencyConverter, and whatever client is pulling it all together.
But really, the Currency class has tighter usage if you eliminate CurrencyConverter and move it's logic inside Currency so that the currency type and operations on that type are bundled together & hidden from the outside world.
Then he pulls the operations on the value / currency pair and bundles those together inside the Money class, and hides them from the outside world.
So IMHO this looks more to me like an example of improving poor or weak encapsulation more than a condemnation of getters -- the getters here are more like accessories to the crime rather than the masterminds. ;)