It's because the bare TLD isn't setup to accept requests, but the `www` subdomain is (it's DNSed to a different IP):
$ curl -v --head https://nushell.sh/
* Trying 162.255.119.254...
* TCP_NODELAY set
* Connection failed
* connect to 162.255.119.254 port 443 failed: Connection refused
$ curl -v --head https://www.nushell.sh/
* Trying 185.199.108.153...
* TCP_NODELAY set
* Connected to www.nushell.sh (185.199.108.153) port 443 (#0)
Most hosts will alias or redirect away the www subdomain, but that's just a convenience. Of course technically foo.com and www.foo.com can have different DNS entries.
My first IT gig, 25 (sigh) years ago, I tried to set up <ourdomain> as an alias for www.<ourdomain>. Seemed to work ok, but somehow I noticed that I had broken email delivery through our firewall, so I reverted the change. Couldn't figure out exactly what was going on, and set it aside.
A few months after I left, I sent an email to a friend who still worked there, and it bounced exactly the same way. Called up my friend in a hurry, and sure enough, they had just finished deploying the same change.
Why even have www.<ourdomain>.<tld> in the first place then, if <ourdomain>.<tld> is entirely sufficient on its own?
It does appear that it's mostly done for historical reasons and sometimes you need CNAME records[1], but overall it feels like it probably introduces unnecessarily complexity, because the www. prefix doesn't really seem to be all that useful apart from the mentioned situation with CNAMEs.
That's kind of why i asked the question above - maybe someone can comment on additional use cases or reasons for sticking to the www convention, which aren't covered in the linked page.
When i last asked the question to a company who only had their website available with wwww but didn't without, i got an unsatisfactory and non-specific answer where spam was mentioned. I'm not sure whether there's any truth to that.
It depends on the setup. Some cloud load balancers like AWS ELB require a CNAME, which DNS (RFC 1912) doesn't allow other records at that level if it has a CNAME.
So, can't put a CNAME on the apex, which probably also has MX records. I think in some cases like Exchange, if it sees a CNAME, it doesn't bother with looking at the MX.
Back in the day "CNAME flattening" or aliases (RFC draft draft-ietf-dnsop-aname) wasn't a common thing, so only real way was to redirect the domain apex to www, and then use a CNAME on the www. You'd probably need a separate service/servers to handle that redirect (at least DNS round robin would work in this case). So yea extra complexity in that case, due to the requirements. Or, give them DNS authority (eg, AWS Route 53).
Then there's the whole era of TV/radio commercials telling people "www dot <name>" that a lot of people type it anyways. You can redirect www to apex, which some sites do for a "clean brand" but now browsers are dropping the www in the UI anyways.
I've also run into plenty situations where www worked but apex didn't. Relatedly, it's a little surprising that browsers didn't default to assuming typing the apex in the browser it would try www first. And recently, now we're getting SVCB and HTTPS DNS RRs along with A/AAAA (and maybe ANAME). Indeed lots of complexity.
While there are plenty of domain which only exist to serve a website, quite a few others have more than that.
With a website, if you want to push it onto a Content Delivery Network (CDN) it is easy to change www.example.com to point (via a CNAME record) to the right place.
If, however, you want to do that with the just example.com and also want to run things like mail, you can not use the CNAME record.
The why is long and boring, but that is the situation right now.
Admittedly, i have no idea why we even need to do that nowadays, but that seemed to work.