> there's no way to disable objective-c interop
Believe it or not, this compiler option is named `-disable-objc-interop`.
> Could someone explain why I should build a language developed entirely by and for writing Apple ecosystem products?
Possibly because you have an affinity for value types, performance, or safety. A language is a lot more than just a checkbox of platforms it supports, although iOS is a pretty large checkbox right now.
> the long list of benefits suddenly looks much, much smaller compared to e.g. JVM, .NET, Go, etc etc.
Swift isn't trying to compete with any of those. I mean sure in the "world domination 10 year plan" sense, but for the forseeable future the bullets that make Java attractive to enterprises (lots of developers, lots of libraries, lots of platforms) are not on anyone's todo list in the Swift community.
Rather, the short-term goal is to compete with C/C++/Rust. So you are writing a web server (e.g. nginx alternative, not a webapp) or a TLS stack or an h264 decoder and buffer overflows on the internet sounds scary, you are doing pro audio plugins where 10ms playback buffer is the difference between "works" and "the audio pops", you need to write an array out to network in a single pass to place your buy order before the trader across the street from you, but still have a reasonably productive way to iterate your trading algorithm because Trump is elected, etc.
As far as JVM/.NET, a cardinal rule of software is that it bloats over time. So JVM/.NET/Go can never "scale down" to the kinds of things C/C++ developers do, but it is less known whether a low-level language can "bloat up" to do what .NET developers do. In fact, C++ kinda does "bloat up", because C++ .NET exists. But that is basically an accident, because C++ was not designed in the 80s with .NET developers in mind, and perhaps for that reason it is not the most popular .NET. To the extent we have a plan, the plan with Swift is to try that "on purpose this time" and see if it works better when we're designing it to do that rather than grabbing a round peg off the shelf and hammering it into our square hole. It probably won't ever be as good at .NET problems as .NET, but perhaps it can get close, for useful values of close.
> you can never just "forget about it for the first draft" the way you can a VM's GC.
Similarly, ARC does not exist to compete with your VM on ease-of-use, it competes with malloc/free on ease of use (and your VM on performance). If your VM is performant enough (or you can afford the hardware to make it so), great, but that just isn't the case for many programming domains, and that's the issue we're addressing.
There is also a quasi-non-performance aspect to ARC that is often overlooked: deterministic deallocation. Most VM memory models are unbounded in that resources never have to be deallocated, but in a system like ARC we have fairly tight guarantees on when deallocation will take place. So if your objects have handles to finite resources in some way (think like open file handles, sockets, something to clean up when they blow away) the natural Swift solution will be much more conservative with the resource use relative to the natural JVM solution. Because of that it may be more useful to think of ARC as a general-purpose resource minimization scheme (where memory is merely one kind of resource) rather than as a memory model or GC alternative itself.