How do people build large front-end applications without a framework, and what do they have to build themselves instead?

Can you build a large front-end without a framework?

You can, and the thread named exactly what you inherit: reactivity. Framework or not, something has to observe changing data, update the interface, and tear down what is no longer needed. Skip the framework and that machinery — plus routing and state — becomes yours to write and to maintain.

The problem you are actually taking on

One reply put it more usefully than any tool recommendation: the thing a framework hides is reactivity. Doing it yourself means choosing how to implement the observer pattern and, harder, how to clean up after it — because references left dangling become memory leaks, and garbage collection pauses are felt directly as an interface that stops responding.

How people said they structure it instead

Separate the three jobs. One reply split a front-end into routing, state and rendering, and pointed out that frameworks try to own all three, which is where much of the churn comes from.
A middle path from the same reply: take a rendering library, then write your own routing and state as thin layers, so the interface you depend on is one you control and can move.
An older layering, from someone describing pre-web desktop work: the interface, then interface logic such as validation and preloading, then translation between the data model and the model the interface actually uses.
Not everything needs to be dynamic. Menus and navigation were named as parts that rarely need any of this.

One commenter described the front-end of their open-source project running on under a hundred lines of framework-ish code, built on the one idea they kept from React — that components are pure functions — and said moving off the framework let them optimise in ways it had made impossible.

The pushback, which was substantial

The premise was challenged directly: React was called considerably more stable than the question assumed, and frameworks were defended as the thing that buys back the time the question wanted to spend on features.
The example application in the question was checked. A reply pointed out it still ships third-party dependencies, just not a rendering framework — so it is not the clean-room case it appeared to be.
The sharpest objection: if migrating through breaking changes already looks like too much work, maintaining a framework you wrote yourself will not be less. What you get from a framework is a structure, even when it is not the best one.

When the thread thought it was worth it

The project is genuinely small.
There is a specific need the framework actively obstructs, or the developer is experienced enough that it costs more than it saves.
The thing being built is valuable enough to justify reimplementing and then owning that machinery.

One reply added a reason to read about it either way: understanding how a virtual DOM is implemented makes it far easier to judge whether the framework you are using is the right choice, whichever way you then decide.