You scatter the code all over the place, making it harder to understand and less flexible (less flexible, because if you want to change something, now you have to change it in six places).
Best practice doesn't mean "make as many classes as possible" although I would probably break up two-pages into a few different functions (large functions, even when they are good code, invite programmers who come later to add to them in a messy way).
If you have to change it in six places it just means that you did something wrong. Keeping those six places in the single file is not the solution either: next time you will need something similar, but not exactly the same you will copy that file. And next you will find yourself changing twelve places.
The good rule of thumb is not to refactor into reusable parts unless you need to do something similar. It isn't hard, at that point, to split things up. Premature design is like premature optimization -- you do the wrong things, or things you never need to do.
And yes changing things in six places means you did something wrong, but that's easy to do when you start by splitting things into six places. The worst, of course, is when developers don't change it when it needs to be changed and instead just keep adding. Once you have something so designed it makes removing and changing code more painful than adding code.