If you know how to exploit it, there's a significant advantage to printing in small chunks.
The serial transmitter has two registers: an active shift register where the current byte is being processed, and a buffer where the next byte is held until the shift register is finished.
Unlike systems with more RAM to spare, the Arduino runtime doesn't allocate a software transmit buffer, so those two bytes are all you get.
So, when you write more than two bytes to the serial port, the hardware immediately transfers the first byte from the buffer register to the shift register, stores the second byte in its buffer, and sets a "buffer full" flag in one of its status registers. The Serial.write() routine sees that flag, and spins in a loop until it's cleared. That means that, when you write n bytes, you spend n-2 character transmit times just waiting, and nothing useful gets done unless it's in the handler for an interrupt that fires while you're spinning.
Given what you've said about the design of your application, where you're updating the LCD about every tenth update of the stepper position, I'd make a sort of state machine for driving the display, and do a small fragment of the display operation on each motor move cycle:
Cycle 0: send the "clear screen" (or "cursor home") to the LCD.
Cycle 1: print degvar.
Cycle 2: print "d ".
Cycle 3: print minvar.
Cycle 4: print "m ".
Cycle 5: print secvar.
Cycle 6: print "s".
With 10mS per cycle, every preceding write will have finished, so you should only see a wait when you're printing variables with 3-digit values (and maybe on the clear/home escape sequence). You could do a little more tweaking, but that's probably beyond the point of diminishing returns.