/su was created for SuperSU, what the layout is in /system is irrelevant, it was never meant to reflect /system. SuperSU installs the most-bits version of its tools (32-bits on 32-bit devices, 64-bit on 64-bit devices) in /su/bin and /su/lib. It has never made the distinction because there's always only one version installed.
I am not proposing anything. I am simply warning that this can potentially end up mixing 32-bit and 64-bit libraries in the same folder, which is a jolly bad idea, and it will at some point end up making some binary malfunction. A work-around is using lib32 and lib64 instead (or if the entire folder is going to be bound, lib32_bind and lib64_bind).
If no special meaning should be held to the layout of /system, then its no problem to use /su/lib32 and /su/lib64. Perhaps it adds additional complexity to falling back to /system/lib (when relevant) but only trivially so. I guess in hindsight SuperSU could have used /su/lib64 when appropriate, but SuperSU's implementation should be treated as a blackbox anyway (imho) so we shouldn't expect SuperSU to fit "our" patterns.
Regarding mixing libraries, can you elaborate? Is it possible for the dynamic linker to load a 32-bit library into a 64-bit binary (or vice-versa)? I've never had luck with that. Additionally, unless these /su/lib* paths are being added to every process's LD_LIBRARY_PATH, how is the linker ever going to even find them? Remember, at least for Xposed, the libraries placed there are bind mounted to /system (where the linker is actually looking).
Lastly, regarding lib32_bind and lib64_bind, are these documented anywhere? I find nothing in Google for them except for your earlier post today. They seem like what we really want anyway (at least here).