From the page:

Depending on the team size, and the rate of commits, very short lived feature/task branches are used for code-review and build checking (CI) to happen before commits land in the trunk for other developers to depend on. This allows and engage in eager and continuous code review of contributions before they land in the trunk.

This sounds roughly like what you are advocating.

The resources about GitHub-flow that I've seen don't put emphasis on the lifetime of branches, only on them being finished at some time, with the completion of a feature, and being deployed immediately after being reviewed.