This was my initial reaction as well, but I appreciate the qs/hash sugaring:

    http://www.domain.com/path/index.html?query1=test&silly=willy#test=hash&chucky=cheese
    
    $.url('?');         // query1=test&silly=willy
    $.url('?silly');    // willy
    $.url('?poo');      // (an empty string)
    $.url('#');         // test=hash&chucky=cheese
    $.url('#chucky');   // cheese
    $.url('#poo');      // (an empty string)

I think that's a bit too much functionality to put down as "sugar".

Agreed, this is the way to do it. The only caveat is that IE has a bug where it omits the leading / on the pathname. You can normalize it with a simple one-liner: http://stackoverflow.com/a/6168370/172322

> Agreed, this is the way to do it.

This sounds like arguing that we should use getElementById&al, addEventListener, and array.length with for loops instead of $('selector').on 'foo' and .each(). While this lib's inner code leaves to be desired in a number of ways, I really appreciate the readability and the lack of need to instantiate a full-blown DOM element then read a property to obtain a simple single result or two.

Not the same thing. jQuery is worth it if you're doing lots of DOM element selection. If the entirety of your usage of jQuery is a single $("#foo").bind(...) call, then it's probably not worth loading the entire library for that.

URL parsing, for 90% of uses, tends to be a one-off need that doesn't really justify the addition of another library. Making decisions about what library to include is about trade-offs; this library is worth it if you need the query string sugaring or are doing lots of URL parsing. But "instantiating a full blown DOM element" to parse a single URL is over-stating the cost of the activity, especially when compared to adding an additional library to your application.