Most of today's apps languages, for example. But also Go documents that there's only a internal ABI that's not stable across versions, so it doesn't serve for most ABIy things, like system libraries. Rust seems to be similar. I wonder what the situation is like in GPU language land...

These languages still allow you to consume and provide C compatible ABIs explicitly but this does not interfere with data optimizations for native data.

Again, provide an actual example. Many “modern” languages don’t ship in compiled form so the important part is mostly just API.

Go and rust can’t be used for system libraries: you have to create C interface. This means that if you have two libraries, both written in rust then they have to communicate through a C layer.

The alternative (what rust does) is to have every application contain a complete copy of every library it uses, which is horrific for performance.

Modern applications languages: Clojure/ClojureScript, Java, F#, C#, Visual Basic, Python, Javascript, TypeScript, PHP, Swift, Dart, Go (included even if it's labeled as a systems language). Of those only Swift does stable ABIs.

Yep, not shipping (native) compiled code is usually how you end up with no ABIs. But these these languages and runtimes still don't really support optimizations of data structures very well, I think it's largely because they weren't specified and implementerd to do it from the start and now there are all kinds of ingrained things about the semantics and estsabilished implementations and user expectations that get in the way of doing big things like feedback based rewriting of data layouts.