LEDE/openwrt rightly like to minimise maintenance effort and binary size overhead where possible so they will often default to switching things off rather than enabling them or having a huge selection of different build options to compile for on every release.
Which arch to use when upstreaming Ci40 was discussed on the #lede-dev IRC. It was suggested to use the 24k arch as this is what interaptiv gets mapped to anyway by gcc https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01408.html. However as you have pointed out the interaptiv core in Ci40 has a floating point unit which we wanted to take advantage of. To do this we needed a new set of arch packages (known as 24kc_24f) with soft-float disabled and a kernel with full FPU support enabled. As you have seen the support for this has been upstreamed to LEDE and we are now just waiting on them to update the build systems to pick up the new target and arch. This seemed like the best compromise but it does however mean that the dsp ASE is not enabled for default compilation. You could off course enable it for your own builds but its not likely to ever get enabled upstream (off course feel free to ask them).
The base support is there as in the device will boot and have Ethernet available (and hopefully have packages to install). Adding RF support for WiFi, 802.15.4 and Bluetooth is planned but currently delayed. You may see one of our engineers do it in their spare time if your lucky.
As for speeding up encryption using the dsp instructions, can't say I've tried but I guess in theory it would. Not sure if anyone else on here has. Note there is also a hash accelerator available on that chip which may also help, see https://github.com/CreatorDev/linux/blob/openwrt-4.4.14/drivers/crypto/img-hash.c but it really depends if your encryption stack/algorithms are going to use the right crypto APIs to make use of it.
Hope something in that spiel of text helps.