Today’s filesystems are more like the NoSQL equivalent of hierarchical databases, which were the very first database design, created in the 1960s, preceding RDBMSs.

I don't think you can really call something a database if it doesn't have a query language, at least in contemporary practice.

And I wouldn't call "cd", "ls", "mkdir", "rm", "cat" and "echo" a query language.

Even the first navigational databases had a proper query language, although radically different from SQL.

Would you call "get", "set", "del" and "rename" a query language? Because they are commonly used commands for Redis.

There are plenty of databases without associated query languages. RocksDB, FoundationDB, and LMDB to name three. "Queries" are generally "list keys in this range" and all of the higher-level metadata you would want to query on (e.g. relations) are encoded in the key. I would absolutely put filesystems in this camp.

"Language" is just an interface. You can SQL a filesystem if you want, and also can build 3rd party indexers that query engines can benefit from.

Exactly! https://osquery.io is one example that

Path syntax with shell globbing is the query language.

Now add find, grep, xargs, sed, awk and put all those together with pipes

Considering things like wildcards and glob matching these don't seem far off from what you'd use in a graph db query language. (E.g. something like neo4j)

Databases have schema that can change (understood without having to scan content) and indexes - beyond trivial ones like "name; content" and "order written to disk".