It might not seem much (and higher level languages usually abstract away the craziness that UNIX sockets are in C), but that's what the OS still gives you in 2020...
The reason no standard interface has replaced getaddrinfo + socket + connect is probably because it's just barely simple enough for common usage in C, and C was never the language you turned to when you wanted to write something short and sweet--that's why Unix environments have always hosted a myriad of other languages. If initializing a network connection were as complex as in Plan 9, doubtless Unix would have provided a more succinct libc interface for the common case
The BSD Sockets API is also close to the simplest possible interface for supporting all the various address and socket option combinations that are possible. (The kernel provides mechanism, not policy.) So even if POSIX, Linux, or whatever included a better standard interface for initializing a connection, it would have to be in addition to the BSD Sockets API (or equivalent).
They are literally a low-level API that happened to be part of IPv4-only stack because DoD had short deadline to get IPv4 ported to VAX and other new Unix machines.
And OS should provide a policy when it comes to networking, otherwise you end up with never ending story of working around other's software to implement them.
More information here: relevant man entry: https://www.unix.com/man-page/plan9/2/dial/
It specifically mentions making a call.
The example even dials "kremvax". Usenet over AX.25 from the 80s. Pretty sure that is _actual_ dialling.
But, I'm curious as to why Go's "Dial" is more powerful than a standard connection in any other language.
The example with calling kremvax over datakit specifically goes to show-off that all that specifies datakit usage is the "dk" string - nothing else.
Similarly with XTI (and other OSI-oriented network APIs), what you are telling OS is "I want to have a stream oriented connection with graceful close, to service Y on host X", and you don't have to care at all whether it will be IPv4, IPv6, TUBA, CLNS over Ethernet, or direct serial modem exchange using HDLC.
Go doesn't have all of that flexibility because it works from userspace, but it reuses the "service, not implementation detail" approach and lets you concentrate on human-readable domain names and service names instead of providing a maze of "hardcoded IP" issues.