i assume you’re referring to my nonnull argument, do you? i’m not sure if you do, or you’ve missclicked the wrong reply button 
as it sometimes happens. it would help if you quote the exact part of my post.
anyway, requesting non-nullability is important for java interop (and java interop is very important) and that’s mostly it. regular scala code probably won’t (and shouldn’t) bother with nullability at all, except converting between nulls and options on java<->scala boundary and also some very rare cases (like matching on any in current explicit-nulls mode or matching on anyval in the proposed explicit-nulls mode). for java interop, nonnull type helps with modelling java nullability markers as in "MINUS_NULL" and the future of explicit nulls - #9 by tarsa
given that there’s an active work on intergration of first parts of project valhalla JDK 28
JEPs proposed to target — JDK 28 review ends
401: Value Objects (Preview) — 2026/07/30
539: Strict Field Initialization in the JVM (Preview) — 2026/07/30
we should wait a few years to see if this proposal will make java interop noticeably worse (e.g. cause performance degradation or nullness impedance mismatch somewhat akin to Object–relational impedance mismatch - Wikipedia), i.e. whether concerns from "MINUS_NULL" and the future of explicit nulls - #12 by tarsa will be valid or not. tiny differences in generated java bytecode can tank performance as seen on e.g. SIMD implementation and Kotlin checkcast incompatibility :: Gryt