Well, if you remove the choice, that can actually sacrifice the ergonomics GP described, because of one of the important differences between stacked and tabbed: directionality.

Tabs are oriented along a horizontal axis; as with hsplits, you move through them by moving the focus left and right. Stacks are oriented along a vertical axis; as with vsplits, you move through them by moving the focus up and down. The reason you want the ability to choose between the two options is (to continue parent's quote of GP) "to allow you to flip back and forth between [relevant pairs of] windows with just a couple keys". To reuse (and better explain) the example from GP:

    [ _ _      Tabbed Browsers      _ _ ]
    -------------------------------------
    |     emacs      |   Tabbed Terms   |
    |                |                  |
    |                |                  |
    |                |                  |
    |                |                  |

This is a root container whose two children are "Tabbed Browsers" and "hsplit of 'emacs' and 'a tabbed container with terminals'". (This root container is a stacking container, and the browsers' part only takes up about one title-bar-height on the screen because something in the hsplit has focus, so the hsplit gets all of the space and the actual content of the browser windows are not currently visible.) The reason it's stacking, and not tabbed, is because this way I can flip back and forth between any browser and any of the other windows with just one key per direction ("focus up" to get to whichever of the browsers was last focused, "focus down" to get back to whichever of the windows in the hsplit was last focused). Additionally, I can get back and forth between emacs and a specific tabbed term (the left-most one) with one key per direction ("focus right" and "focus left", of course), and I can get back and forth between emacs and any of the terms with 1+2=3 keys round-trip ("focus right" to get from emacs to whichever of the tabbed terms last had focus, "focus parent-wards then left" to get back to emacs). Critically, if you were to change any single one of the stacked containers in this layout to tabbed, or any of the tabbed containers to stacked, then you would be sacrificing at least one of these three properties.

So, the choice between stacking and tabbed matters. I'm not saying you can't have this choice in a scrolling tiling window manager. (Does Niri have stacking and tabbed containers? I hope so.) I'm also not saying that you or anyone else has to want to make that choice (it's okay to prefer a "simpler model" where you scroll around to get to all of your windows). What I am saying is that the author of TFA thinks that with traditional tiling window managers like sway, you can't have "very many windows open" without "constantly swapping between fullscreen and non-fullscreen views and running out of workspaces", and this is simply not true. (Perhaps worse, in the next sentence, they dismiss the solution out of hand by saying "don't get me started" on nested tabbed/stacking containers, because they're "the least ergonomic Band-Aid™ for the space issue I've ever seen", but it seems to me that declining to give a full treatment to that subject may actually be why the author's never seen it done ergonomically. But now I'm speculating.)

------

BTW, since anyone still reading is probably a completist: at the top, I said that directionality was "one of the" important differences between tabbed and stacking containers. The other one is how much space their title-bar areas take up vs. how many children they have. Stacking containers are O(n) in the number of children; tabbed containers are O(1). Interestingly, combining this with the directionality property yields an interesting result: in sway, there is a sort of asymmetry between the horizontal and vertical dimensions.