It’s a performance optimization for rendering a large amount of html. If the DOM had all the items in memory it would perform much worse. Thankfully browsers are working on a feature where you can keep the markup in the DOM for things like CTRL-F without hurting performance.
Granted the main reason such a technique is needed is designs that avoid pagination.
We had web pages with big lists and tables in the DOM 20+ years ago, they were fine. The difference is that now we use web frameworks that do work proportional to DOM size many times per second.
Call me a conspiracy theorist, but I think it's all a plane to make it harder for people to save stuff. If the content just stays there after you loaded, you could just save the page as HTML and, if there wasn't a lot of javascript shenanigans, it should save it okay. When you add this element, this doesn't work anymore. I'm pretty sure instagram, for example, does that with the intention of making it harder for people to save profiles.
I am usually just a backend developer, but for a little reporting application that I built, I couldn't get the UI team to do a UI in the short time that I had to build it, so I had it output some basic HTML. About 10000 list items. Rendered imperceptibly fast on my browser.
Then because of $mandate, the report was moved to the team's standard React UI frontend. Now it takes 5 seconds to load and only gives you like 100 items at a time, so Ctrl-F is broken. Also, filter dropdowns somehow did not work until they fixed it, so it appears like the select tag was not fit for their design and they rolled their own.
Pagination is part of it but most of it is simply using inefficient JavaScript frameworks and not learning how the DOM or CSS really work. The maximum number of elements you could have on a phone a decade ago was measured in hundreds of thousands (median) or millions (iPhone), and the hardware & browsers have gotten faster. The problem is that you have had a lot of very turnaround focused developers shoveling out code which uses deeply nested elements, poorly-scoped event handlers, etc. which mean that too many DOM elements are created, unnecessarily touched during updates, and the overall complexity means that on the off chance someone opens their browser’s profiler they won’t see a single obvious problem and will likely proclaim it unfixable and say something like “the DOM is slow”.
There is a special place in hell for every web developer who does that.