Why is the orchestrating method in a Template Method typically declared final, and what breaks if it isn't?

Marking the orchestrating method final is what actually enforces the pattern's entire purpose: a fixed sequence of steps that subclasses can customize in one specific place but never reorder or skip. If that method is left non-final, any subclass can simply override it wholesale, and nothing in the language stops that override from calling the shared steps in the wrong order, skipping one entirely, or adding unrelated logic between them. That silently defeats the guarantee the pattern exists to provide — a resource-cleanup step like closeFile() could be skipped by a careless override, reintroducing exactly the bug the pattern was built to prevent. The final keyword is not a stylistic choice here; it is the mechanism.