I've used Dancer quite a bit. Some for larger apps (30+ pages)
This is how I typically lay out a Dancer app. Starting with a top level directory of application name, say "MyApp", I put the routes in different directories instead of jumble them all up in one file. As an example, lets use an app that handles and tracks customers and orders. So something like this:
│ ├── Component
│ │ ├── Customer.pm
│ │ └── Order.pm
│ ├── Customer.pm
│ └── Order.pm
Routes/Customer.pm would handle basic requests like GET /Customer/list and POST or GET Customer/1
While routes handling json/ajax only requests (from jquery ect) would be in Routes/API/Customer.pm. Routes/API.pm would be an api for stuff that doesn't directly involve a Customer or Order object (perhaps returning json from an inventory table or something)
This is just sorta a method I made from various best practices from other frameworks. Perhaps its barftastic, but I haven't been complaining about it.
I'm actually kind of surprised that we haven't seen a return to that style, with more modern sensibilities: each route directly mapping to a file containing the route's procedure body + any view templates for that route; a single "common" file at the project root containing dependency-imports and model declarations, etc.
In the end, it wouldn't actually work like old PHP—you'd still actually have a single entry-point and all the code would be preloaded rather than loaded into an ephemeral request context—but you'd be able to code as if the opposite was true.
Reminds me a bit of the "oldschool sensibilities" of coding with something like Löve2D, actually.
To be clear, Mojolicious advises a layout like above from the beginning for any serious app (and even provides a utility to automatically convert Mojolicious::Lite apps, for the most part), but when it's in production already and Mojolicious lite makes it a little too easy to put that off when it's so easy to just add another route... Well, I have only myself to blame. :/
I'm really interested in well designed route structures,especially for sites that include both HTML and JSON variants of their data. It's API design any way you look at it, which is always a hard problem, but I haven't come up with general rules that I'm quite happy with yet. Guides or example sites are welcome.