I'm a little unclear of the connection there... In fact I would say that your question addresses three separate (but related) concepts.
If you use LIMI 2 to enable interrupts, then /all/ scratchpad memory used by the console interrupt function is off limits. Not only >83C0 through >83DF, but also the GPL Workspace from >83E0 through >83FF. Settings certain bits in there just right can actually lock the console up in the interrupt routine.
If you use LIMI 0 and thus never enable interrupts, you can use all of scratchpad.
Now, this is (slightly) unrelated to how you poll the VDP for the end of frame. If you enable LIMI 2, of course, you should not poll the VDP at all - if an interrupt is active when you LIMI 2, then it will automatically jump to the interrupt code and run it for you.
If you run without interrupts, you can either use CRU bit 2 to check for an active interrupt pending from the VDP, or poll the VDP Status register. Due to race conditions inside the VDP, we tend to recommend the CRU method.
Now, whether it's less reliable is an interesting discussion. I would say it's not only NOT less reliable to poll, but faster overall. To defend that argument, I need to look at the organization of a typical TI program.
Typically, TI programs run with the interrupt disabled (LIMI 0). Then, at a central point of the program, interrupts are briefly enabled and then disabled. (LIMI 2/LIMI 0). If the VDP has an interrupt pending, the LIMI 2 will enable a vector to the interrupt handler.
If the program is structured in this way, then it is arguably equivalent to polling. In fact, if you have your own interrupt that you want to run, it's faster to poll, because there's no overhead used running the console code. Instead of "LIMI 2/LIMI 0", you would just have "TB 2/JNE xxx" (assuming you can keep R12 zeroed for the CRU
Both approaches let interrupts run with the same frequency and at the same point in the code. If the code runs for longer than one frame before enabling interrupts, then it will skip frames, the same as the TB version does. The only difference is whether it's the code or the 9900 interrupt circuit that looks at that CRU bit. (and, of course, in the TB version you jump directly to your own handler, instead of the ROM code running first).
Some systems and programmers DO run the other way, with the code running freely with interrupts enabled, and jumping to the interrupt handler any time they like. On the TI this is typically discouraged, though, since you can't safely access VDP memory in that case (as an interrupt will corrupt the VDP address without notifying you). It's totally possible to structure a program this way, however. In that case, polling is actually harder to do well. In fairness, though, I don't think many people code this way on purpose just because of the issues it causes with VDP access.