Back when I wrote about how the mere 'presence' of a URL on a web server wasn't a good signal, I casually mentioned that you were more likely to have everything answered with a HTTP 200 status on things that weren't really 'web servers' as such, but which were just using HTTP. You might ask why you'd use HTTP if you weren't a web server, and the answer is straightforward and widely known: HTTP has become the de facto default communication protocol. Today, if you need to create a system where you pull some information from something or push some information to something, you're most likely to use HTTP for this purpose. In the process, the software may be coded in such a way that it provides a default answer to nearly everything.

In my view, the reason that people see HTTP as the default communication protocol and why so many things use it this way is simple; it works well enough and it's there. Because web servers have become common, pretty much every modern programming environment will have HTTP clients and simple servers in their more or less standard libraries. Some environments (like Go and Python) directly support them in the standard library; others, such as Rust, defer these to third party packages but have good implements and make it easy to use them. There's also wide agreement on and support for a way to transport data over HTTP, in the form of JSON; again, most everything you want to use supports this relatively easily. The conceptual model of HTTP is also simple, in that you can basically view it as an RPC system.

(An additional bonus of using HTTP is that you generally get a bunch of tools and features more or less for free, although people may start asking you for extra things in your software once they start taking advantage of this. For example, people who run your 'web server' behind a reverse proxy often start asking you for some basic URL mapping features.)

You don't have to use HTTP and in a number of cases you're better off doing something else. But it's pretty certain that doing something else will require you to write more code, and you'll be cut off from the ecology of tools that support HTTP and can act as ad-hoc clients and servers for testing, diagnosis, and so on. Similarly, you don't have to use JSON as your data encoding over HTTP, but if you don't you're probably writing more code and putting yourself through a harder time (cf).

(Using HTTP will in theory also give you a number of best practices, although how applicable they are to things that are only using HTTP as basically a transport protocol is an open question. There are ideas you can borrow from 'REST', though.)

None of this is new or a novel observation, of course. I don't know when HTTP reached this state of being the default client/server communication method that got used, but it's certainly been quite a while.