> although I don't follow their reasoning

I think it is sound. Imagine what happens when the filename contains:

    ' && shutdown now && '.mp3

Of course that makes sense now.

Anyhow here's an example of how I would use the while loop and process substitution in a BASH script:

  declare -i file_count=0
  while IFS= LC_ALL=C read -r -d '' file; do
    file_count+=1
    printf "file: %s\n"  "${file}"
  done < <(find . -type f -name '*.mp3' -print0)
  printf "Processed %d files\n" "${file_count}"

I think that'd be tricky to do using just a find/-exec command.

I see, but now you are essentially operating on multiple files, at once, so the serialization makes some sense. Although for just this, I wouldn't write the operation in bash at all:

    find . -type f -name '*.mp3' | wc -l

Honestly I don't really view the shell / filesystem interface as a security boundary. I use the shell mainly for (automation of) interactive use, so any screwup due to e.g. quoting issues is my own fault, maybe even of using stupid filenames. Shell is a great language to connect streams of different programs into each other, not so much for doing any work. If I do that, I would reach for C.

The serialisation is just to work around the fact that filenames can have any character except for \0 which is why the "-print0" is used. It doesn't by itself allow for concurrent processing.

You're right about just using "wc -l", but I was just trying to demonstrate how you can set variables. A real use would be doing more than just counting files as your example would likely be quicker (assuming that calling an external programme is quicker than running a naive loop in BASH).

I am guilty of using BASH for stuff that most people would use a different language for - I just find that for system admin work that BASH is just at the right level of abstraction for me and is ubiquitous.