My real distaste here is for the idea that, if you want to use a database, you should do so by passing through a "web development toolkit" (how Mojo describes itself in its documentation), regardless of whether you're doing web development or not.

Well, if your distaste is of the idea, then I'm not sure I could convince you otherwise, and I'm not going to try to. I'll just give a few thoughts on why I like it - make of it what you will (in German we say über Geschmack lässt sich streiten).

I have heard criticisms of Mojolicious that are something along the lines of: since the framework doesn't want to have any external dependencies, and doesn't want to split into multiple modules, this has led to several reinvented wheels (if I had to name some: Mojo::Date, Mojo::File, Mojo::URL, or Mojo::JSON already had good existing equivalents). I do understand the Mojo authors' choice of this design, as well as the concerns about it, and I do think the design may become an issue if Mojolicious becomes less well-maintained than it is. And of course there's the valid argument that loading Mojo can take more memory than the equivalent DBI-based code, though it's also worth pointing out that Mojo apps are often designed to be long-running processes.

I think that the Mojolicious distribution does have some very nice modules to offer that can be used separately from the "web framework" aspect:

• Mojo::DOM - the only good, modern HTML and XML parser that I know of that supports CSS selectors, and a very nice API (also through its integration of Mojo::Collection).
• Mojo::IOLoop - there are other event loops (e.g. POE, AnyEvent), but again, it has a nice API (especially compared to POE) and built-in support for several different events and protocols. For example, it makes writing both TCP and WebSocket servers and clients pretty easy (for example, see Apache Pulsar modules).
• Mojo::UserAgent - again, there are of course others, but in this case I'd say two USP are its tight integration with both an HTML/XML and a JSON parser, plus its support for asynchronous operations (on that topic, see also Future::Mojo).
• Mojo::Pg, Mojo::mysql, Mojo::SQLite, and Mojo::Redis are separate distributions that depend on Mojolicious and follow the same API (though sadly their API isn't 100% unified). For example, I recently used Mojo::Redis's pubsub and it was quite nice and easy to integrate into my app because of it uses the same asynchronous Mojo::EventEmitter base as the rest of Mojo.

And note that using any of the above modules in isolation doesn't turn your application into a web application...

Now, I'm not advocating that one should use Mojo for everything. Just a few days ago I reached for a combination of HTTP::Tiny, JSON::PP, and URI, even though Mojo has equivalents too, mostly because I didn't need all the other features Mojo offers, and the former two of those modules are in the Perl core. Next to the obvious use of Mojo for web applications, I think anytime an application needs several of the components that Mojo provides, one can benefit, even if one isn't writing a web app.

In terms of my subjective feelings about it: its API lends itself to beautifully concise code, making it easy to both "whip stuff up" and write larger applications, and all in all it just feels very Perlish to me.

my response would have been the same (and probably worded the same)

IMO, the wording "if you don't feel the need to drag a random web application framework into your code" without further explanation makes it seem like the primary intent is to insult the framework or my node rather than providing information or arguments to the OP. And please feel free to provide the OP the equivalent of my code with DBI ;-P