So as i understand it the 'use case' is for coercing 3rd party types into your own type hierarchy. Suppose you had:

  trait Foo {
    def bar(): Int
  }

and 3rd party library had

  final class FooBar extends java.lang.Object {
    public int bar() { /** **/ }
  }

you could simply define your methods to take in a:

  type BarAble = { def bar():Int }

But obviously if the library class is not final, you can simply do:

  type ThirdPartyFoo = FooBar with Foo
  ThirdPartyFoo <: Foo

Removing structural typing wouldn't be an improvement to my mind. It's the sort of thing you use maybe once a year, but when you do it's extremely useful to have around. It's a bit like saying that removing the ternary conditional operator in Java would make a big difference to developers' lives.

I think the kind of features you use maybe once a year are a bad thing to have in programming languages - ease of reading is more important than ease of writing.

I should also point out that it's a feature which I don't believe detracts from readability. It's pretty clear from looking at code which uses ST what it does. There are examples in this thread.

It's a feature that you will use directly maybe once a year when adding it to a library, but I then use that library (and indirectly that feature) virtually every day. YMMV but we've found it very useful.

Ding ding!

(That's the answer I'd give if someone asked me this question)