Yes, code inside a single-cyle timed loop is at least as efficient as the same code outside a single-cycle loop (if anyone has a weird case demonstrating otherwise, it would be fun to see). Not every FPGA function can run inside a SCTL (single-cycle timed loop), though - for example, many IO functions require more than one cycle to complete. It also may not make sense to put one or more single-cycle loops, each running a single iteration, inside a larger standard loop, because then you might force more cycles than necessary if the compiler could otherwise combine them in a single cycle.
I try to use single-cycle loops for as many of my long-running loops as possible, usually in a state machine so that even though some operations require multiple states (cycles), all of the code gets the benefit of executing in a single-cycle loop and I can determine exactly how many cycles it will take to get a result. I don't see any opportunities to do that here unless your IO can run in a single-cycle loop, which depends on your hardware.
In the case of the error you're seeing, the easiest thing to do would be to reduce the precision of one of the fixed-point operations, and see if it fixes the error without resulting in an unacceptable loss of precision. If you can't lose precision, then you need to rethink your math and try a different approach. I don't know what hardware you're using so I can't see what precision the analog input values are, but you have the subVI configured for a 26-bit input. Does your analog input have that much resolution? I don't see any NI cRIO modules with greater that 24-bit resolution. I'm also not sure why you have the reciprocal followed by a multiply, instead of using a simple divide - but the compiler likely optimizes it to the same operations. It would be interesting to know if changing that makes a difference, though.
