The reason why it works when installed as a third party application, is that on installation, the package manager scans the APK and checks if it uses native libraries, and if such are found, it stores which ABI they used (since it only installs libraries for one single ABI, so the info about which choice was made needs to be stored somewhere).
For an application that is installed system wide with the libraries in /system/lib, it’s not clear that this particular application depends on some app specific libs in /system/lib (that aren’t available in a 64 bit version in /system/lib64), so the package/application manager can’t know that this particular app requires a specific ABI and thus runs it in 64 bit mode.
Setting LOCAL_32_BIT_ONLY probably only affects whether it should be compiled in 32 bit mode, not in which way it should be run.
An old (and probably outdated) report at http://www.slideshare.net/hidenorly/investigation-result-on-64-bit-support-in-aosp seems to suggest that the native libraries for apps should go into /system/lib/apkname, but this doesn’t seem to be true on an actual Android 5.0 system. Instead, the libs seem to be in /system/app/appname/lib/abiname. Some apps seem to have native libs for multiple architectures (e.g. both “arm” and “arm64” as abiname), while others only have one single architecture (which would force the process to be started in that ABI mode).
So I think you need to alter the mechanism for how you install your native libraries (you said you manually modified device.mk) – I’m not familiar with how to build own apps as part of an AOSP build, but I’d recommend trying to look at the existing bundled apps how they do it, this commit may be related: https://android.googlesource.com/platform/packages/apps/Terminal/+/1a161f75%5E%21/