Actually, from my perspective, to focus on a "main goal" (rather than a primary benefit) and then question it, doesn't really seem to make sense.

You say "(kind of broken) SSL system" - any yes, there are many criticisms that can be laid at SSL's feet, and many flaws; but when you're building a secure system it's a matter of synthesis - it's a bit like cooking, you add the ingredients which make sense for what you want to achieve.

And re: point 4, for instance, when you have many megabytes of code which expect to be dealing with HTTPS Secure Cookies, perhaps *that* is more important to you than point 1; or perhaps point 5 is.

But let me put that argument to one side for the moment, and address your question as-stated: 

 The answer to that is "maybe"; there's an informative comparison here to be made with IPsec Authentication Headers*, commonly known as "AH"; it provides an authentication framework but leaves you (again) to bootstrap your notion of "identity"; you have to work out your own preferred solution for host identity and validation.

Also: in the traditional internet we're used to the idea of "1 IP Address => 1+ Websites"; you can run a bunch of different websites with different domain names on a single machine with a single IP address, but in that model IPsec fails** because it authenticates *IP addresses* rather than DNS domain names.  

In Tor we traverse almost all boundaries between ISO Layer 3 and 7 - the Layer-3-alike Onion address provides AH-like authentication but is as visible to the user as a Layer 6? (7?) DNS domain names; and it's arguable that Onion site HSDirs are their own version of Layer-2 ARP, likewise. Tor is basically a separate networking stack to TCP/IP, and should maybe be treated as one - but this raises the question: "What <element of the network stack> are you trying to authenticate/validate, in some proposed SSL-replacement?"