To me that does not count as a duplicate, but as a usability and scalability feature.

* "find ... -delete" probably just calls unlink, just as rm does, which is a libc feature. No subshell spawned thus lean and fast.

* "find ... -exec 'rm {}'" allows to run a command without xargs, but does not allows you to filter and transform the stream. Propably will spawn a subshell for each call.

* "find ... -print0 | sed 'bar' | grep -v foo | frobznicate qux | xargs -0 rm --" is where the power lies. A few more subshells created.

This, to me, shows that 'find' actually does what it should do, and allows you to choose the best way you can do it WRT the task at hand.

and massive gui programs are?

I would had thought a much simpler and more direct example of functional overlap would have been 'more' and 'less'...

'less' is actually an improved reimplementation of 'more'.

On my Mac, for example, 'less' and 'more‘ are hardlinked:

       $ find /usr/bin -samefile /usr/bin/less
       /usr/bin/less
       /usr/bin/more

And invoking 'less' as 'more' most probably makes less drop into a compatibility mode.

Also, 'man more' brings you to the less(1) page, which contains the following snippet:

       Less is a program similar to more (1), but which allows backward  movement
       in the file as well as forward movement.  Also, less does not have to read
       the entire input file before starting, so with large input files it starts
       up  faster  than text editors like vi (1).  Less uses termcap (or terminfo
       on some systems), so it can run on a variety of terminals.  There is  even
       limited  support  for  hardcopy terminals.  (On a hardcopy terminal, lines
       which should be printed at the top of  the  screen  are  prefixed  with  a
       caret.)