What the author calls the product model is just capitulation. There's no agreed-upon requirements and no scope. Each product thus occupies the team in perpetuity. That's obviously bad for business.

I would argue that this model does describe maintenance, but a very bad form (due to the permanent addition of ill-fitting new features to justify the expense). In fact, I think that scrum's failure showed us that projects (what scrum apologists try to disregard as "waterfall") are the way to develop software. Iterations are the way to maintain it. One can put small features into the latter, but everything that's large or has business value deserves a project. You don't know the requirements yet? Then go get them before we start development!

Note that projects don't need to be long and projects can easily hang onto an established agile maintenance process, e.g., for releases and other infra. But they need to be planned properly, have an agreed-upon scope and don't need to fit into arbitrary sprints.