I2C LCD causes problems

If the code it is working, it compiles, which means you are getting a warning not an error. There is a big difference between warnings and errors.
For why you are getting the warning: See post # 19.
If you don't use a variable after you assign something to it (which is what you were doing) you will get a warning.
If you use a variable that is not declared you get an error which is what happens if you remove the declaration of the variable named status.

Like I said in post #8 you can't eliminate the time overhead of writing to the display, but you can reduce it significantly by doing things differently like making the code smarter about what/how it writes to the display and/or speeding up the i2c bus clock rate.
Also, if possible you may want to see if you can eliminate the floating point math.
Floating math is much slower than integer math so eliminating the floating point calculations can buy just a little bit extra time reduction.
Will all that be enough, I don't know.

I should mention that running the i2c bus at 400kHz is pushing things beyond their ratings. While it may "work", it may not be fully reliable depending on voltages, wire lengths, temperatures and may cause the display to get garbled.

In terms of another motor library that uses interrupts, I'm not sure if there is any other library as I'm not familiar with that type of device.
But that said, the AVR i2c support is 2/3 h/w and 1/3 software. The AVR Wire library uses interrupts and has some polling in the ISRs. Depending on the sensitivity of jitter in the calling of functions in the AccelStepper library, it may or may not be possible to keep things glitch free when using the AVR Wire library.
Some of it may depend on how many characters are written to the LCD at once.

--- bill