I think it may be more appropriately called the mid-tier. You have your back-end handling storage, low level validations, complex business logic, service integration and coordination, background jobs, etc. You have your mid-tier with the implementation-specific validations / logic, template rendering, etc. And then you have your front-end with (as appropriate) all the client-side stuff (validations, logic, and rendering).

It's worth considering the source, in this case. Nicholas has spent a lot of time both employed full-time and as a contractor at organizations that operate at a massive scale. This solution works if your application, architecture, or even engineers would benefit from additional abstraction.

I do take issue with one point he brings up, however. He mentions the mid-tier communicating with the back-end over HTTP(S). Unless you have some need to serve your API exclusively over HTTP(S), why not use something with a little less overhead (like a message queue)?

I think it makes more sense if you think of it as "domain of the front-end engineer".

There's certainly an increasing number of developers who are focusing more on the front-end plus Node.js, often for connecting backend services and providing a RESTful API.