Any FP code generated by the compiler is potentially impacted for the negative. If you use some of the bits under patented functionality, i.e. AV transcoding, I would anticipate a negative impact. But in that case you have to build it yourself and probably have gone to NEON anyways.
Do you have a reference
For wrtpac devices > mamba the change cut the FP registers available for use in half; assuming the compiler respects options provided. I have not bothered to go and look at the assembler churned out, but as the device that did not work now does...
OpenVPN would depend on SSL library used. I would expect no impact with openssl, I have not taken a close look at mbedtls so not sure.
Easy enough to load an image with / without on the two partitions and test whatever the bits are that are of concern to you. But the change to go back from whence we came is trivial, so I just do that and fuhgeddaboudit.
Turris Omnia with a Marvell Armada 385 88F6820 features
half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
and this commit just castrates the CPU capabilities.
There is no point in sticking with OpenWrt if the repo is not able to diversify the CPU architecture for the target class but instead penalising device owners.