Let it do it's 32 bit thing internally. The editor should take care of truncating and dithering down to 24 or 16 bits or whatever you specify for your exported files. 32 bit float allows sufficient internal processing headroom for the calculation math involved in changing levels, summing channels, and all other calculations done on the files. Once those calculations are done, the 32bit > dither and truncate > 24bit output step is harmless and better than forcing the editor to estimate and round off the math to work within just 24 bits.
Think of it as analogous to the well understood advantage of recording 24bit files even though the release format will be 16 bits. In that case 16 bits is fully capable of containing the full dynamic range of the music, but the additional headroom is welcome and helpful in relaxing the requirement to get levels set perfectly. In the case of the editor, if it is working with 24 bit files to start with, it needs more than 24 bits of calculation space to fully accommodate the calculations. Once the calculations are done, the data can easily fit in 24 or 16 bits. It's about transparency of processing.
Similarly on the sample rate side of things, many plugins have the option to oversample the incoming data before doing their processing (allowing for less step filtering which is likely to be more transparent and artifact-free) they then sample rate convert back down again to the original sample rate of the file at their output.
Most editors have the option to save a 32bit version, which might make sense if storing an intermediate working version of files that are still being edited, but makes no sense as a final output format as it would be total overkill.