This puts in words what I have argued on with so many people.
It is so easy to fall in the trap of using best practices in tests and to end up with a generic test framework that is specific to your company/service and that is also making refactoring of your actual so much tougher.
Really, I would summarize that blog post by saying one thing: Be pragmatic, keep tests simple and easy to understand without much browsing and investigation.
On another topic, this makes me think about go/golang. The recommended approaches in the go community are mostly very pragmatic. The language itself forces you to solve issues in simple ways. As an example the table-driven tests approach is a way to simplify the way you structure your tests.