I don't think that's necessary. The 'friendly' language could have a write(file, data) command implemented at a lower level in an 'unfriendly' language as:

  // try, catch, error handling, etc.
  // omitted for clarity
  friendly_write(file,data) {
      open(file)
      write(file, data)
      close(file)
  }

It would be an engineering tradeoff of code brevity for possibly lower IO performance. Sometimes it might be worth it. Other's it might not. Java's design reflects the engineering opinion in favor of finer grained control. This is consistent with it's heritage in the line of Algol inspired languages.

How would your new OS/hardware know when the "use" of the resource is complete ? Maybe the dev wanted to read just 10 bytes from a 1 GB file, maybe 100 bytes... maybe its a telnet connection which is never supposed to be closed and just kept in a pool ?

For a very small benefit of "automatic closing of resources" this looks like a huge trade-off.

Disagree that it is a small benefit. Resource management becomes so unwieldly that there's little difference between a 100k line application in Java and a 100k line application in C with regards to memory/resource management. Are you saying that moving beyond C is a "small benefit"?

And it's easy to determine when the use of the resource is complete: when there are no active pointers to the resource (the circular reference problem I don't think can happen with external resources like files).

Some languages (Python, Ruby, probably dozens of others) have constructs along these lines

  with f = open("data.txt")
    print f.readline()

The file is automatically closed at the end of the block. Those languages also have explicit open/close/seek calls to let the developer implement more complex cases.

Btw, the os closes any open file when the program ends.

Yes, you're correct that os's have some kind of rudimentary reference counting for files, but it's very inchoate and not designed as the primary method of handling file references.

There's nothing wrong with Java, but there's been a lot of effort over the last two decades put into designing alternative languages for the JVM. Scala, Clojure, Groovy, and JRuby are examples (though none are primarily in the direction of automatic file handling).