I'd wager that most people just don't get that the second "arg" (composed of multiple args) to find is an expression. Expressions are, somewhat unfortunately, code, so there's essentially a mini DSL there.

  find -name '*.md' -and -not -type d

Of course, then it becomes more obvious why there are parens, why those parens must be escaped for the shell, etc. E.g.,

  find '(' -name '*.md' -and -not -type d ')' -or '(' [...] ')'

I think once someone groks the nature of the expression args, then find becomes easier to start working with.

The most messed up part in my mind though is that while most things in find are clearly helping the expression towards its goal of "true" or "false" on whether to include the file or not in the results, some, like -prune or -exec do so but with side-effects. And since they're usually invoked primarily for their side-effect, it isn't immediately obvious that they even return a value, or are participating in the expression itself. (-prune is true, and -exec depends.) And this is where it becomes important that `find`'s -and & -or are short-circuiting, too. (In a purely logical expression, it wouldn't really matter except as an optimization.)

People also sometimes omit -and, which I'm not a huge fan of the legibility of. (But using -and makes it not POSIX; you can do -a but ew. which brings me to the last bit…)

macOS: the find there requires the starting-point arg; so my examples above, on macOS, would all need to be,

  find . [expression args...]

… which is lame. Brew install GNU find and be done with that.

While I agree with globbing (or fd) for interactive use, I think for scripting I'd still say "you might want find"; there are limits to arg list lengths (see xargs) that (esp. recursive) globs can exceed; unless you know you'll never glob the world, find might be appropriate. Also:

  echo *nope*

Globs will betray you on the zero-match case. (`man bash` & cf. `nullglob`.)