Att det inte används på andra ställen är inte så konstigt, Apples OS är ju ett hopplock av BSD, NeXT och lite nya saker. IOKit hade tydligen en föregångare i NeXT där man körde ObjC, men till MacOS blev det alltså en nedskalad variat av C++ (de vanliga sakerna när C++ används i realtidsfall är borta, exceptions, RTTI och lite sådant).
Är just det IOKit används till, d.v.s. drivers, som man primärt tittar på eventuellt tillåta Rust i Linux och Windows.
Sedan finns det egentligen inget alls som hindrar någon från att skriva vilka delar som helst i Linux-kärnan i C++ (förutsatt att man slår av exceptions, RTTI etc) eller Rust (no_std varianten som är en den av standarden, "no_std" refererar till "inget standardbibliotek utan bara språket").
Så för egna saker behövs egentligen inget stöd i ett OS för att använda de språk som saknar beroende på "runtime". D.v.s. de språk som kan fungera även om man bara skapar passiva bibliotek och där det finns en rimlig väg att interagera med C ABI. "Ingen runtime" diskvalificerar i praktiken alla språk med GC, de går att modifiera (har gjorts med bl.a. Java) men vad är poängen för då har man ju skapa något nytt som inte längre följer någon standard...
Då väldigt få utanför embedded implementerat C11 kan man t.ex. inte skapa ett multitrådat program i standard C, det går i standard Rust.
Lite coolare är att om jag ändå har C11 (eller C++11, Java eller C#) så kommer kompilatorn gladeligen kompilera program som innehåller potentiella data-races. I Rust kommer ett sådan program inte kompilera i normalfallet (då det är ett systemspråk finns är det ändå möjligt att öppna vapenskåpet om man verkligen vill skjuta sig i foten).
Då du gillar Java: på många sätt förhåller sig Rust till (modern) C++ som Kotlin förhåller sig till Java.
Modern C++ har fixat till många av vårtorna och lagt till saker som man idag känner är självklara delar. Men då det finns brutalt mycket existerande C++ kod måste man göra alla nyheter inom ramen att fortfarande behålla bakåtkompatibilitet. Man är väl medveten om hur bedrövlig Python 2 till Python 3 övergången gick just p.g.a. att man släppte bakåtkompatibilitet. Väldigt mycket som kommit in i senaste versionerna i C++ och saker som är plannerade för C++20 och C++23 finns redan i Rust.
Rust är C++ "done right", i bemärkelsen att båda riktar in sig på prestandakritisk systemprogrammering och man interagera med C till noll kostnad (även om i princip alla programspråk kan använda C är det långt ifrån effektivt).
Java har samma problem här, finns allt för mycket skrivet i Java för att man ska kunna bryta bakåtkompatibilitet. Mycket saker som läggs till i Java finns redan i Kotlin, men en rad vårtor i Java som man undvikit i Kotlin kommer stanna i Java då man annars bryter bakåtkompatibilitet. Kotlin är "Java done right".
Men är bara i projekt där man startar from scratch där språk som Rust och Kotlin kan bli aktuella. Vi lär veta om 10-20 år om folk tyckte det var tillräckligt värdefullt så dessa är mer normen då. C lär stanna dels då det idag är en portabel assembler samt är det definierar den ABI i princip alla andra språk kommunicerar med omvärlden.