Of course I mean defending against the charge of overcomplexity rather than defending overcomplexity itself.

I am sure there are arrogant commenters around, but these commonly used design patterns applied in this case have made his code worse for next to no practical benefit. Besides test speed, there's no reason you'd want to divorce your Employee model from the database it lives in -- the fact that ActiveRecord reflects against the database to decide what attributes an Employee has should be a clue that coupling to the DB is the point of using it in the first place.

> who insist that certain commonly and successfully used design patterns have no place in the world.

I don't think the architecture skeptics claim as much. I believe you're restating the claim in a more extreme way that it's commonly expressed, thus making it clearly indefensible.

The claim isn't that certain architecture patterns have no place in the world. Rather, the claim is that those patterns aren't a good fit for most Rails apps.

Pretty much any pattern (that's not a commonly-accepted antipattern) has some good use case, somewhere.