The list of comments on a submission tells you how many comments exist, but the comment count is also made explicit at the top of the page directly underneath the submission title.
If one person comments multiple times, their user name will appear multiple times on the page, despite being the same every time.
All the timestamps are presented as relative timestamps, which means they're all dependent on the current time.
Now this is a very simple page, and it's not so important that everything be updated live. But if it were, you'd need to update every single timestamp on the page, keep all of the usernames in sync in case a user changed their name, insert new comments while also updating the comment count, etc. There is a lot of redundancy in most UIs.
In fact, I vaguely remember one of the early React blog posts using a very similar example (I think something to do with Messenger?) to explain the benefits of having a data-driven framework rather than using the DOM as the source of truth for data. For a messaging application, it's much more important that everything be live, and that elements don't end up out-of-sync.
If you just rerender everything every time, then it's no problem to keep the whole UI in sync. But you probably don't want to render everything all the time - that's unnecessary work, and will break any stateful elements in the UI (such as form inputs that will get reset with every render). That's where the idea of React comes from: write code as if the whole UI is being rerendered every time, but internally only rerender the parts of the UI that have changed.
Now that has its own disadvantages, and I think there are similar approaches out there, but the point is that keeping UIs in sync is a surprisingly hard problem.
