Known bug in their code actually. They meant to do a full state reset at the start of a print but had a bug. (Same bug which can cause your Z platform to slip down a tiny amount after Z homing but before the print actually starts. Seen by people with heavier, modified Z platforms or really well aligned Z rods and a well lubed Z leadscrew.) Once the bug was fixed, it was obvious that the intent was to assert temps at the start of the print (like most printers do) and not after homing. But MBI has a lot of oddity in their starting gcode. E.g., the dropping motor currents while heating up.... Why not first heat up, then engage the motors with homing? Then there's no need to drop the motor currents at all. Eliminates entirely the issue they had with their under-sized power supply. (An issue which does not exist on the clones and thus the commands to drop and then raise the motor currents can be removed entirely without needing to re-order the starting gcode.) Net, net, MBI's stock starting gcode is not as well thought out as it might be.
And, FWIW, I've had these discussions directly with their engineers and they agreed with these points: the bug as well as the fact that a simple re-ordering eliminates the need for dropping the motor currents and that turning motors and heaters off at the initiation of a "print" had been their intent. The latter since the "print" might really be some other process put into an SD card file or sent over USB. They were concerned about safety and not accidentally leaving heaters on and so sought to put in safeguards. In this case, intent was that if you wanted the heaters truly on, then you'd turn them back on. Had they not had that bug, they would have surely realized the issue and turned the heaters on earlier in their starting gcode. But they didn't. And round about their 7.2 release they stopped fixing most reported bugs: they were putting all their efforts into their next Gen printers. This bug wasn't discovered until 2013.