Certain functions, by default, are created along with it. These include the accessors (url-protocol), (url-server), (url-port), and (url-path); the constructor (make-url); the copier (copy-url); and the type predicate (url-p).
Suppose that you are using packages, and you wish to make this struct available to packages which import the one it's defined in. The only things you *have* to export are the accessors, but the constructor is useful too and there's no good reason not to export it. The same goes for the copier and the type predicate.
What about the name of the struct, itself? Sure, you can test with (url-p ...), but you can't test with (typep ... 'url) unless you export the name. You also can't use type designators which reference the struct, such as '(or url string), which you might very plausibly want to use to refer to a url OR a string which specifies one.
You could use '(or whatever-package::url string), but it's best to reserve double colons for REALLY unusual situations, to make it easy to recognize and search for those situations. This hardly qualifies.
Of course, "url" is going to be a very common variable name. There are going to be accidental situations where other packages use that symbol without any obvious indication that the symbol really comes from the URL package.
But think: is this going to cause problems? The same issue could be raised regarding standard type names ("cons" and "member" come to mind as ones which are likely to be unwittingly used as variable names). It doesn't cause trouble, because Common Lisp has separate namespaces (if you can call them that) for variables and types. The only way where you'd get into trouble is if "url" were used as a global variable by some package, but it won't be - that's one reason it's good to have naming conventions such as "*name*" for global variables.
So, if you're trying to export a struct completely, you should always export: the accessors, the constructor, the copier, the type predicate, and the name of the struct.