From the perspective of someone with AuDHD (both Attention Deficit Hyperactivity and Autism Spectrum) there are several pros and cons to this whole debate that I will try to present as objectively as possible. Though, they are still from my own personal point of view and experience. (As the famous saying goes: Your Mileage May Vary.)

• Having some kind of table of contents can be helpful in tracking the reading progress.

  Especially with a properly configured CSS using the system colors LinkText and VisitedText to properly highlight all links as well as those that have been clicked on (as in, those that are contained in the browser history). Those system colors, together with the other 10 defined in the standard, make it possible for websites and e-books (ePub is after all nothing more than several HTML, CSS and media files grouped into a ZIP file) to be accessible to readers with varying visual needs. Such as different font sizes or color [contrast] combinations. All browsers and e-book readers have several predefined color schemes (e.g. Light or Dark, depending on your environment), where the reader can modify each system color [variable] to suit their own needs; or even create a completely custom color scheme. Though, this breaks when web developers do not use these system color variables.

• By default the main anchor for a HTML file is the first h[123456] in the body of the file or post. Though the table of contents generated automatically by BCTS gets the text from the title element of the page/post. These table of contents appear at the bottom of each organizational page, as well as the left sidebar.
• Links that point to anchors within the same page only get included in the browser history when you explicitly click on them, NOT when you scroll past the anchor. Thus defeating one of the intended benefits of having a table of contents at the top of a huge file/post.

  Would you jump to the start of the file after finishing each chapter to click on the link for the next chapter? Or do you just continue scrolling and reading until you reach the end of the file/post?

• Due to my AuDHD I much prefer reading my stories in chunks of about 1.500 to 3.000 words, instead of 10.000 or even 75.000+ words, as has happened more frequently in the old days.

  The larger posts made sense in the days of dial-up internet, where you paid by the second and maybe even at long distance rates. Back in the day I would open the post, then hang up the modem and read the story while off-line. But in today's world with 24/7/365 connectivity, that just is not necessary anymore, nor does it make a lot of sense either.

  Having smaller parts/chapters together with the automatic table of contents in the sidebar, makes it much easier to track my progress through the story. And it also makes it easier to go back for a memory refresh of the story context.

• Having smaller story chunks also encourages more frequent and candid reader feedback. The sooner you reach the „Add a comment“ link, more likely the reader will leave some feedback on a thought provoking or humorous point of the story.

  Even if the story as a whole is fully finished and edited, I imagine that authors are still delighted to receive some form of feedback or thank you from their readers.

• The concept of „master document“ and „sub document“ has been around in word processors at least since 1989 when I learned about it with WordPerfect 5. The idea was to keep each chapter or sub-chapter in its own file and link them together in the master document. The formatting styles, front matter, table of contents and index all resided or were generated within the master document. And you could easily adjust the order of the chapters by moving a single line of text code, and all page numbers, references and cross-references would adjust correctly with a simple regenerate. Not to mention, maintaining a consistent formatting across a document with tens if not hundreds of pages. And it was even possible to edit the sub documents through the master document, as if it was just one monolithic document.

  Using this approach, you can even easily maintain the cast of characters within the framework of the story without loosing your place in the story every time you want to consult or edit the character list. It is a separate physical file, but still an integral part of the story as a whole.

  This concept is akin to the idea of a simple template mentioned by another commenter.

• Serialization has the potential benefit of capturing more readers. By posting a chapter once or twice a week, you keep the story on the front page for longer. Assuming your story has 30 chapters and you post twice a week, your story will be on the front page for 15 weeks, instead of only one week if you post it in one huge chunk.

  Some readers will even sniff into a random chapter, like what they read, and then start reading from the beginning. I personally have discovered more than one interesting story by either „accidentally“ clicking on a link or by seeing an intriguing chapter blurb.

• Unless it is from an author I know and really appreciate, big posting will more often than not languish in my „to-read“ tabs and eventually just be closed unread. With small chunk postings it is much easier for me to reconnect with a story in my „to-read“ tabs.

Why would you want to „reinvent the wheel“ over the automatic table of contents built in to BCTS? Just keep in mind the principles of 8P and KISS: „Proper Prior Planning Prevents Pathetically Piss Poor Performance“ and „Keep It Simple Stupid“.

A lot of headaches can be avoided by separating the form from the function, and concentrating on the function during the majority of the writing and editing process. Leaving the form, or formatting, for the latter stages, with the help of [formatting] style in the word processor (or text editor of choice) results in a freer creative process and more consistent presentation at the end.

Using the concept of master/sub documents might just help streamline the „putting words on paper“ process. While at the same time preparing your opus for chapter posting on BCTS and the automatic table of contents provided by BCTS.

This is my €0,02 worth of advice and opinion.

I have adopted and adapted these ideas into my own process of saving good on-line stories into e-books for my own library and personal reading enjoyment. With Sigil (by e-book editor of choice) I can very easily split large HTML files into smaller chunks, either manually or by inserting markers (often with search and replace) for a more consistent split all at once. File renames are cascaded through the whole document and table of contents is very easily generated based on the h[123456] elements.