I certainly used UUCP back in the day, for what most folks used it for back then: email and USENET. UUCP itself is mostly straightforward, albeit a bit cryptic, as was everything back then. But it's certainly something I'd file under "be amazed it worked at all".
Point to point, UUCP is pretty basic. The craziness is the whole routing side.
With the Internet, routing is buried deep in the system. The vast majority of users are unaware of it, even at a basic level.
With UUCP it was a first class concept. The whole point of the bang path was to describe not just where to go, how!to!get!there. Mind, this wasn't the absolute case. There was the idea of "well known hosts" where you could forward stuff (notably email) and it would find its way to its eventual destination, we used UUNET for that back then. There was this whole mess of processes of folks publishing public routing data. At the time, it was less about complaining about the warts of the system compared to simply praising that it worked at all!
From a practical point of view, I had my own little USENET/email node tied up via a 2400 baud Hayes Smartmodem to A Guy who I think hooked up through UCLA. At the office, we used UUNET and we also set up our clients directly from our machines. UUNET was pretty much exclusively mail and news.
For the office, we struggled getting UUCP to be seamless. We used it to move software over for installation on client system. It mostly worked, it sorta worked, but wasn't necessarily reliable for us. Or, we were just impatient. When we wanted to send a file, we typically wanted it "now", not "later", so not really wanting to wait for the retry timeouts to come around and have another go at it. All fine when things are working great, but when something goes awry, it's all timeouts and queues and other annoying "not right now" things. Our backup was typically shoving stuff over Kermit directly.
I would have like to have been able to leverage the uuxqt (I think it was) capability of running remote scripts, that way we could have done remote installs and such.
Ubiquitous connectivity pretty much spelled the demise of UUCP. Even with modems today, you're likely better off lighting up a SLIP or PPP connection and then just using normal TCP/IP protocols.
But, that said, TCP/IP is still pretty heavy weight in comparison to a simple file transfer using a reliable protocol. UUCP didn't any of the common protocols of the day (X/Y/ZMODEM, Kermit, etc.). It COULD, it just didn't. You could extend it today to do it if you were so motivated. So, if you had a modem on an TCP/IP-less micro-controller, UUCP could certainly be leveraged to get data in and out of a network of such machines.
All that said, I can see an interesting use case for it, even today.
Notably, because we have a lot of layering in our modern network systems. For example, you have a simple network: A <-> B <-> C. A can connect to B, and B to C, but not A to C.
So you can see a contrived case where, using an IP based transfer mechanism, you can have someone uucp from A to b!c, A connects to B, moves the data, then, later, B connects to C (or vice-a-versa) and finishes the job. This makes the transfer an ostensibly "single step" process for the person on A, while the UUCP process manages the hurdling of firewalls an what not.
Now would someone use UUCP for that, vs, say, rsync via cron, or something else? Eh, who knows. But, that may more simply be unfamiliarity with the process more so than inappropriateness. If we have anything today, it's a 100 and 1 different ways to move data.