I am unconvinced. Any absolute deserves close scrutiny, and "real nouns only" is an absolute. In this case, it fails my test. I find that many things I work with (especially huge Java libraries) tend to have convoluted and difficult-to-understand webs of classes with the most confusing pieces named things like "FooManager" or "FooController". So the author of this piece is reacting to a genuine excess.
But Travis is overreacting. The REAL goal is to find a collection of abstractions that is powerful enough to accomplish what the program requires but as simple as possible (and as local as possible) to allow humans to comprehend (and maintain) it. There are quite a few times when I have found that one of these "verb-like" abstractions (a word ending in "-er") made things more comprehensible.
For example: the Gang-of-Four patterns "Builder" and "Observer" both end in "-er" and strike me as being well-named. "Builder" is an object with no purpose other than to create (initialize) another object or data structure. HAVING such an object is useful when something requires extensive setup or initialization, because it is easier to understand if the extensive initialization is kept separate from the core functionality. "Observer" is the name for an interface of things that observe... the names of interfaces FREQUENTLY work well as "verbs" since the interface frequently represents "anything that does X".
Similarly, I have often had a class such as "DatabaseConnection" and then created "DatabaseConnectionWrapper" -- a class whose purpose is to wrap a DatabaseConnection to do something like logging, error reporting, pool flushing, driver-bug-patching, and so forth. Suggestions that I call these "LoggingDatabaseConnection", "ErrorReportingDatabaseConnection" and so forth misses the key point: a different mix of features may be required at different times (eg: logging in QA but not in Prod); the fact that they are transparent wrappers that can be added (or not) in any order is a key feature of the design.
So my own advice would be weaker than Travis'. Instead of "Don't make objects that end with -er.", I would say "Be wary of confusing objects; those ending in -er are often confusing."