Hear hear.
For me it starts with “What is the problem that the application/feature is solving?” then “How do we test that this implementation is solving that problem?” from there you design scenarios intended to test (Or “explore”) the answers to those questions. approaching the application “as a user” can be extremely variable because you can define user as - another service, a data store, infrastructure, a bad actor, etc. I might be misunderstanding a thing or three here; but I find I have to make sure Im not only thinking of user interface as an entry point to Exploratory Testing.
I was working on a product in which a service was a pod in a kubernetes node. there could be many running at a time. A developer whom I admire wanted to do some of his own testing of the service he was working on. So he created a program that would execute from the IDE to do a variety of things with the service. When I found out about it I made grabby hands and demanded that be put into the source repository. I used that to perform a variety of more expanded exploratory tests. We found some good defects and understood a lot more about a remote (other company) service we had to interact with that was (intentionally) obfuscated by lacking and poor documentation ( cough google cough) We documented the findings and activities just like any other testing and made it available to anyone who might later have to refine that service. IMO, is every bit as much “testing” as any other activity.