I can take a crack at a list. (Though most of what the original list says is applicable in web dev, too.)
How are you measuring things? Who's doing that work? (Every measured interaction requires a bit of custom coding and testing.)
Who's actually REVIEWING the data you're measuring? Who turns that into an actual todo list?
Who is taking the backlog and figuring out which things actually meet real customer needs?
Who's talking to customers, for that matter? Are the features you've planned actually solving problems, or is the whole team being driven by best guesses?
Once the backlog's been prioritized, who's doing the initial research to get a scope and requirements put together? Who's defining what "done" looks like? Who's breaking the scope into individual tasks?
Who's handling the micro-interactions and polish that make a website feel good to use?
Who's checking for regressions? Who's going through the test results and opening issues to track regressions?
Who's leading feedback efforts? Who's actually talking to customers? Who's turning customer feedback into action items?
Who's keeping tabs on all the different projects? Who's making sure those projects are all pointed toward the same goal posts? Who's paying attention to timelines and noticing when a project is dragging on too long?
Who will tackle that mystery error that's keeping the site from auto-deploying? Who patches the bug in the tooling that's blocking the whole team since bumping some dependency?
Who can cover for the dev that's on vacation? Who's making sure knowledge is being shared so that dev CAN go on vacation?
Who's doing a11y checks? Who's implementing a11y fixes?
Who's on IE11 duty? Who's checking the mobile experience on feature phones with 2G connections?
To repeat a few from the quoted thread: who's on i18n? Who's doing recruiting? Who's running QA and turning QA feedback into action items?
I could probably go for days on this. Big teams can cover more ground and tackle things that small teams will likely never have the ability to prioritize.
Obviously, adding more people adds different challenges: how to coordinate tons of people, stay consistent, manage quality, etc..
Big teams and small teams alike come with trade-offs; scaling in an effort to boost velocity without considering those trade-offs is a recipe for disaster. (But so is staying small at the expense of meeting user demands.)
