Intel and ARM
I assume Intel is probably interested in use for embedded controllers. The infamous Management Engine, the embedded controllers to do thermal management and power distribution (any CPU that has a base and a boost clock probably has some embedded controller managing that), wifi controllers, ethernet chips, etc. But who knows? They certainly have the resources to make a ridiculously fast but low-powered RISC-V CPU if they wanted to do so, to compete with the ARMs that are digging into the datacenter sales.
ARM? Oh yeah, in years past the ARM Linux kernels were almost entirely model-specific; there was no standardization to what GPIO pins, what addresses devices were at on the various ARM busses, and no plug and play or ACPI-style data structures to find out (except the ARM Microsoft Surfaces, they used some PC-style ACPI tables since I suppose Windows on ARM could use them to find devices.). Like pre-plug-and-play ISA, the "board support package" kernel would just have I/O addresses, what interrupt the device uses, etc. hard-wired (but worse because NONE of the devices have standard addresses, on the ISA PC at least the keyboard, system timer, IDE controllers and a few other things had standard addresses, I used an ISA PC with Linux and devices with jumpers for IRQ and I/O port, I built the stuff as modules so I could feed the IRQ, I/O, and DMA channel as module parameters instead of having to stick junk into my kernel boot line.). Finally within the last 5 years or so, the Linux developers came up with a way to have a generic ARM kernel that'll boot on most systems... but it involved just putting this giant table of DTBs ("Device Tree Blobs") listing what addresses the devices are at on each and every older ARM board; the newer ARM boards finally started putting a DTB into the board firmware so bootloader and Linux can parse that to determine where the hardware is.
They standardized on u-boot on ARM many years ago to load the Linux kernel, but the early boot process on ARM was not standardized at all either, on some systems (quoted from u-boots web page) "U-Boot takes some responsibilities of a classical firmware (like initial hardware setup, CPU errata workarounds or SMP bringup)" while on others "it's main purpose is a bootloader".
So yes... it'll be very good for RISC-V to take care of this now rather than having years and years of systems that require model-specific kernels or a table that expands more and more every year as new boards come out, bootloader that may need to be way more than a bootloader depending on what board it's running on, and so on.