Be aware that there are two issues with reading the status register directly from the VDP.
The first one is software - every time the status register is read, it clears the sprite collision and vertical interrupt bits. So when you read it manually, there is a chance you can interfere with the interrupt routine (which only matters if you are using it - allowing LIMI 2 in your code). The interference is that sometimes you'll grab the bit, and sometimes it will, all depends who gets there first. If you get it first, the interrupt may not happen on that frame. (No real negative consequences, but if you are using it for motion or music, they may slow down).
The second is hardware - if you read the bit at the exact time it is set, the update is sometimes lost. This is usually only an issue for collision if your sprite is only one row tall or only one row collides, since it's pretty much impossible on the TI to interfere with two sequential scanlines in a row.
If you aren't using the interrupt routine at all, feel free to carry on as you are - it's just sometimes helpful to have the information above in your back pocket in case you see unexpected behavior later. if you want to work around those issues, AND you /are/ using interrupts, the interrupt routine stores a copy of the status register every frame at >837B - you can read it from there instead of from the VDP directly. (Again, only if interrupts are enabled every frame).
Don't be afraid of directly polling - hundreds of programs have run just fine for years doing so. Even Extended BASIC does it that way (for CALL COINC). It's only recently we've really dug down deep enough to start understanding those things.