Sounds like what C++ shops used to do: enforcing a subset of C++, prohibition on anything else. However, each shop has its own subset.
You've done a very sensible thing. Yet, I'm pretty sure that most if not all the features you've decided to use are found in Kotlin. I'm not saying you should use Kotlin, as it's not ready. I'm bringing it up to demonstrate that what people want from Scala and what its designers had in mind are two completely different things. What people want from Scala is Kotlin, but what its designers built is a Java-Haskell hybrid with macros.
And there's a bigger problem. Do you shy away from Scala collections? Because I have no idea how the types works there, I didn't want to spend who knows how many hours just to understand how a simple list is coded, and I certainly wasn't going to use something I couldn't understand. So while you may easily understand your own code, I don't know if your team understands this simplest, most basic of libraries.
The company I work for is a Scala shop, and we've found success in codifying our coding style using the Scalastyle linter. The combination of a linter and peer code reviews has been very helpful for us in figuring out which language constructs and libraries we use and which we shy away from.