Some of those are good questions, and some are kind of the wrong questions to be asking.
Dependencies and size of distribution Mojolicious consists of a single distribution with a zipped tarball of just over 500KB in size. It has no non-core dependencies. It installs on most modern systems in under a minute, including the execution of its high-coverage test-suite. When I execute the tests in parallel, I get a full installation in about fifteen seconds. There are a few helper modules you can install if you need some more advanced functionality, but they're optional. And it's up to you to decide on what resources to use in establishing a database connection; it's completely neutral on the model layer.
Track record of incidents? You should probably instead be asking if the cultural infrastructure of a given framework facilitates reporting of incidents, if the reaction time to incidents is quick, and if the solutions are on target. There are a few incidents in Mojolicious' history, and all of them were dealt with quickly, transparently, and accurately. Something as complex as a scalable web framework that has no incidents could be an indication of poor reporting, or opaque practices. It is to be expected that problems will turn up in any project. It's how the problems are handled that matters most. I would say that Mojolicious's track record is quite good; there is a substantial user base, only a few known issues that were resolved transparently, quickly, and correctly.
Coding style (in relation to robustness)? I don't see coding style and robustness at odds with each other. As a matter of fact, coding style can contribute to robustness. Mojolicious's coding style is intentionally minimalistic, both in appearance and in "action at a distance" (magic). Furthermore, Mojolicious has something like 19000 tests for 11000 lines of code (going from memory here). The design policy is that a feature is only a feature if it is supported by tests. New features are not added if they break tests, except after a documented deprecation cycle, and even then, usually other means of achieving the goal are used that don't break existing tests. Breaking existing tests goes heavily against the Mojolicious team's philosophy.
Advocacy for defensive/secure programming, strict template language As moritz suggested, Mojolicious templates escape output from embedded Perl by default. You have to intentionally use the <%== .....%> to get un-escaped output. Mojolicious's templates run under strictures. Stash values that aren't reserved words become variables accessible in your template. If you attempt to access a variable that hasn't been declared, or passed in via the stash or flash, you'll get a strictures violation. But the templates are embedded Perl. However, Mojolicious doesn't force you to use its templates (as good as they are, you may have another preference). The Mojolicious documentation demonstrates how to use a different templating system if you wish.
encoding/escaping of input/output While you (the developer) are permitted to access raw input, the normal means of dealing with input in Mojolicious handles encoding/decoding for you. What you do with the input is up to you, and safety can only go so far as you don't misuse user input.
Strictures and warnings Any class that inherits from Mojo::Base has strict enabled by default. I can't remember if warnings are enabled by default or not, because I always enable them explicitly anyway. In development mode, strict violations (and other fatal errors) will route you to an error page in your browser that displays some of the surrounding code. In production mode, you get a sanitized failure that doesn't give away any information.
XSS, XSRF, SQL Injection Mojolicious doesn't manage your database interactions for you, and has no say over how you craft your interaction. So asking if Mojolicious prevents SQL injection attacks is like asking if the car's seat belt mechanism has a means of preventing flat tires. XSS: The fact that Mojolicious's templates default to escaping Perl output is a design feature intended to prevent XSS attacks. Mojolicious's session cookies are signed with a SHA1 digest based on the cookie's content, an "application secret", and the cookie's credentials. This prevents Mojolicious from accepting a session that has been forged in any way. By default, Mojolicious session cookies expire after two hours. Any cookie that doesn't match the SHA1 hash will be ignored (as in, won't be allowed to be used), and the corresponding session becomes invalid. I don't know if this prevents all XSRF vectors, but it seems pretty secure.
The application secret (used in signing cookies) can be set by the app itself at any time. Whenever the secret changes, the signature on the cookies will no longer match, and all sessions will be invalidated. This can be a quick-and-dirty way to force all users to log in anew.
Mojolicious's routing allows for 'bridges'. A bridge facilitates a request being routed through a callback function before arriving at its destination. The callback has to return a true value or the destination won't be available. So it's easy to put your auth checks in a bridge. Users who don't meet the requirement won't be routed to their requested destination.
You should visit the Mojolicious website to read for yourself what features are documented, what precautions are taken, and so on. If, after reading all that, you have additional questions, I encourage you to check out the Mojolicious mailing list, as well as the #mojo channel on irc.perl.org. There is always someone listening at those two locations who can answer specific questions.
