First binary compatibility is not a thing in embedded/iot etc at all even today. Firmware are always compiled directly for specific targets.
That's the only market currently embracing RISC V. They know exactly what software will run on those SoCs, and they can churn out an SoC that has only bare-minimum support for that software/firmware. Hence the appeal of RISC-V.
If we talk about future high end socs for smart phones, PCs, server etc, then de facto standards for what official extensions are required will be established by the market themselves. For example if someone plans to do a Risc-V smart phone soc, then they will of course collaborate with an owner of a ecosystem/OS (e g Google/Android), otherwise their product won't have a market.
And there are very few reasonable Risc-V extension combinations for the high-end at a given time anyway.
Let's all take a trip down memory lane by remembering about an Intel SoC called Baytrail. Baytrail had several variants, and Intel practically paid people to use these things (contrarevenue, for the tablet variant specifically). Because Baytrail was cheap-as-in-free, enterprising low-end market OEMs began using the tablet-oriented Baytrail in desktop applications, which wasn't "supposed" to happen. Baytrail-T found its way into set top boxes and mini PCs. Fortunately for people who bought those . . . things, Baytrail-T supported all the same instructions (I think) as other Baytrail products, so it's not like software that worked on one Baytrail wouldn't work on another. Baytrail-T products just ran things very slowly when used in hardware applications that were inappropriate for the SoCs. Not that Baytrail-D was that much better, but oh well.
Now imagine if Baytrail-T had been missing some key ISA features of standard Intel x86 CPUs of the day (and I'm not talking cutting-edge-for-its-time SIMD like AVX). Like . . . I don't know, SSE3 or SSE4. There are probably a fair number of x86 programs out there that won't even boot without SSE4 today, and there were probably some in Baytrail's time that required at least SSE2 or SSE3. A dodgy PC vendor could sell you a Baytrail-T for a song, preloaded with an OS that would boot and some software carefully selected to work without needing whatever ISA extension was missing from this hypothetical Baytrail (let's call it Bayfail). Try loading some third-party x86 software on there and whabam, now you can't run it because . . . SSE2/3 unsupported? What's that? Consumer is confused. Not like the OEM would care. Of course this hypothetical Bayfail would only be intended for, I don't know, an embedded application or a closed-OS consumer device that will never run third-party software anyway (without some hackery). If Intel couldn't stop real-life Baytrail-T from finding itself in applications for which it was never intended, do you think the RISC-V world will fare any better?
Show me a RISC-V vendor that tries to sell a cheap phone SoC that doesn't support RISC-V P, and I'll show you a chincey OEM that will try to slip that SoC into phones that can access an app store with apps that (sometimes) use packed SIMD (presumably as an equivalent to 128b NEON). Someone buys this mysteriously cheap phone, only to discover that now they can't load a whole raft of applications that are supposed to be RISC-V compatible.
ARM dodges this neatly by setting standards for its own designs that are targeted to a specific market. For consumer devices, you can either have Cortex-M for embedded microcontrollers, or you get an A-series chip. And . . . that's about it! As long as the OEM chooses an A-series SoC, all the same instructions will be supported no matter what across that generation. No exceptions. There are some weird circumstances where you have ARM with custom ISA extensions (notably Apple), but that's for a closed software environment. You run exactly one OS from one vendor with apps that follow that vendor's design guidelines (or else). Bottom line is, though, that any application that will run on A76 or A77 will also run on A53. It may be slow on A53, but it'll run. It'll even support NEON.
RISC-V doesn't even try to set standards like that. It really is aimed at embedded where maybe the OEM doesn't want a full-fledged Cortex-M, opting instead for something simpler and cheaper that only needs support for a fraction of the functions offered by ARM's cheapest offering. Also, at least the last time I checked, not all of the RISC-V ISA extensions are "frozen", which means they are subject to change. That could be a mess. And then you have the possibility of propietary ISA extensions . . . ugh.