Every interrupt has a pending bit and a priority level. The priorities are 0 to 255, where 0 is the highest.
When the hardware event occurs, the interrupt's pending bit is set. The NVIC (Nested Vector Interrupt Controller) looks at all those pending bits and priority levels to decide which interrupt to actually run. It's called "nested" because an interrupt with higher priority (lower number) can interrupt another currently running interrupt with lower priority. On Teensy 3.x and 4.x the NVIC implements up to 16 levels, so 0-15 are all the same priority, 16-31 are the same, and so on. ARM designed NVIC this way so software can always use 8 bits for priority numbers and the hardware can implement less for cost savings. Some of the other popular ARM microcontrollers implement only 4 or 8 levels.
So in your hypothetical case where interrupts are disabled for 1.5ms shortly after the 1ms SysTick timer interrupt, immediately after you re-enable interrupts the NVIC will run whatever pending interrupt has the highest priority. Usually on Teensy that will be SysTick because it's configured with priority of 32. Most interrupts default to 128. The hardware serial interrupts default to 64. So if during that 1.5ms time some serial data arrived (hopefully not more than the FIFO can buffer) and you're using attachInterrupt() on some pin which changed during that time, first the SysTick timer interrupt runs because it's priority is 32. Then the serial interrupt runs, moving the received data from FIFO to the larger buffer in memory. And finally the pin change interrupt runs. The SysTick and serial interrupts are quick. But if your pin change interrupt takes more than 0.5ms, and if it's at the default priority of 128, when SysTick triggers again its interrupt will run, interrupting your pin change interrupt code. Likewise for more serial data incoming. That's how nested interrupts work.
The pending state is only 1 bit. So if you were to disable all interrupts for more than 2ms, the second time SysTick triggers the pending bit will already be set. The hardware has no way to remember SysTick triggered a 2nd time. When interrupts are re-enabled the SysTick interrupt will run, but only once. You will effectively lose 1ms on the millis() count. As an example that's come up a few times, people have tried to compare various speed of addressable LED libraries. If you use millis() or elapsedMillis to measure an interrupt-blocking library like Adafruit_NeoPixel, you will usually get a result that looks like it took only 1ms no matter how many LEDs. Of course that's impossible, because the communication is at 800 kHz, so updating 300 LEDs with 24 bits each must take at least 9ms. If you measure OctoWS2811 which doesn't block interrupts, you'll see the true time. Blocking libraries appear to be faster only because the millis count is lost when interrupts are blocked for more than 2ms (or potentially even just slightly over 1ms, if the blocking happens immediately before the SysTick trigger sets the pending bit and then re-enabled just after a 2nd SysTick hardware event).