If you've got some management core somewhere in your silicon you can, with RISC-V, give it a MMU but no FPU and save area. You're going to be writing custom embedded code anyways so you get to save silicon by only incorporating the features that you need instead of having to meet the full ARM spec. And you can add your own custom instructions for the job at hand pretty easily.
That would all be a terrible idea if you were doing it for a core intended to run user applications, but that's not what Apple, Western Digital, NVidia are embracing RISC-V for embedded cores. If I were ARM I'd honestly be much more worried about RISC-V's threat to my R and M series cores than my A series cores.
Sure. The FPU is optional on a Cortex M2, for instance. But those don't have MMUs. You'd certainly need an expensive architectural license to make something with an MMU but no FPU if you wanted to and given all the requirements ARM normally imposes for software compatibility[1] between cores I'd tend to doubt that they'd let you make something like that.
[1] Explicitly testing that you don't implement total store ordering by default is one requirement I've heard people talk about to get a custom core licensed.
Apple has an architecture license (otherwise they could not design their own cores, which they’ve been doing for close to a decade), and already had the ability to take liberties beyond what the average architecture licensee can, owing to being one of ARM’s founders.
That would all be a terrible idea if you were doing it for a core intended to run user applications, but that's not what Apple, Western Digital, NVidia are embracing RISC-V for embedded cores. If I were ARM I'd honestly be much more worried about RISC-V's threat to my R and M series cores than my A series cores.