The pattern can work, but the domain matters, the test type matters (unit, integration, ui) and the trade-off associated matter.

e.g. If I am running a long-running UI-test scenario, I absolutely don't want test-5 to walk through 80% of the UI that was already exercised in tests 1-4. I am creating test coupling, but I'm saving cost/time by doing so.

But, you'll also hear why not to do this, because it creates test coupling / breaks atomic tests, which is generally seen as bad.

If that is a local integration test and those early steps run is millis? Then maybe we keep things uncoupled to allow the system to exercise the pathways without explicit expectations.

The question was less about speed and more about not having the same code duplicated over and over across tests. Which is how I read the article talking about it. Allowing one test to "depend" on another makes it clear they use the same setup (presumably with the second test going "a bit further", but not necessarily).

I wouldn't have a problem with something like

    test-1:
        setup:
            do-the-thing
        verification
            assert-the-thing-happened
    test-2
        setup:
            depends-on: test-1 // tells it to run test-1's setup
            do-the-next-thing
        verification
            assert-the-next-thing-happened

    GIVEN
       Some initial setup
    WHEN
       I run command
    THEN
       The result of that command is what is expected

I actually use the GIVEN/WHEN/THEN keywords in my tests, to make them easier to read