You can use your own convention if you like, but in your OP you say that MIT 6.004x says that their convention is to have a pipeline output registered.
But there are better reasons than 'it's their convention'.
Why are you adding a pipeline register into the random logic of gates F, G and H? Because they are not fast enough. Not fast enough for what? Not fast enough to receive inputs on this clock cycle, and have the result ready to be used somewhere next cycle. So by adding the output register, we are being explicit about where the timing must be right.
When designing a pipeline, the easy bit of the timing is 'can one register drive another, in a clock period?'. The hard bit is 'can one register output ripple through the random combinatorial logic I have between stages, in a clock period?' Using an output register means that all the difficult timing is under the control of the designer of that module (or the student answering the question), and the interfaces are easy timing only.
Using a pure register at the beginning or end of a pipelined process gives you the cleanest I/O timing with respect to the clock. If you need to connect your process to something, that's important as it allows for easier calculation of setups and holds, and tolerance for extra delays and clock skew between processes. If I go to the modules catalogue, I'm more likely to be able to successfully use the design with the cleaner interface timing.
If you find you have connected two processes, and that there are two registers between them when there only needs to be one, it's trivial to remove one of them. So where the two processes meet, you generally have a register that you could call either the output of the previous process, or the input to the next. The MIT convention is that you call that register part of the previous.