The CPU is able to execute armhf, but there are some catches to this.
Within the kernel the kernel mode is normally arm64 (ARMv8-a). Given the correct interrupt, the CPU will switch to arm32 (ARMv8…basically a combination of armhf+NEON being supported) and run the armhf, but it isn’t possible to run both at the same time. arm64 is the “native” mode/architecture, arm32 is a “foreign” mode/architecture. The kernel support is likely not the problem.
In user space there are combinations of libraries and the linker which support almost any non-trivial program, e.g., even a “hello world” type application links to libc. The very first R23.x releases supported only the arm32 user space. Starting in R24.1 arm64 64-bit user space was supported. As currently used you will have only the native arm64 user space. You could add armhf as a “foreign architecture” by adding the armhf linker and all required libraries in their 32-bit form, but this is very invasive and requires a lot of additions.
I have not tried to do this, in part because of the complexity and in part because performance would be dismal while doubling the disk space for user space support. If you want to do this though what you would need to research is adding a foreign architecture to the apt/apt-get package tools so that not only is arm64 shown when searching for a package, armhf would also show up. Then you would add an armhf version of the linker, libc, and anything which your application might want to link against.
Keep in mind that armhf support for CUDA stops at something like version 6.5. You cannot get newer CUDA support under armhf…versions newer than 6.5 require 64-bit.