Almost none of what you list is that important to me when evaluating whether to take on a dependency. Here is what I care about that could be construed as "weight", in no particular order:
- How often are new releases with breaking changes made? More frequent releases means I have to spend more time keeping up with the dependency. Apply this to all public dependencies as well.
- What is their policy on minimum Rust version? A missing policy---or at the very least, a missing CI entry for a fixed stable Rust version---means a lot more work me in tracking down that information myself and potentially redoing that for each new release.
- How many other crates directly depend on the crate in question? If a lot of other people are using it, then that typically implies some level of maturity. It means that many people, not including myself, found this crate worthwhile to use. It also means that if there are problems with this crate, then there is a higher likelihood that they will have been found and debugged before I hit them.
- Who is responsible for maintaining the crate? What does their track record look like?
- What does the documentation look like? Is it comprehensive and contain examples? Or am I going to need to read the source code to understand it? Missing documentation means I need to spend more time learning how to use the crate.
- Does the crate depend on non-Rust libraries? If so, I might expect to spend time dealing with that (or passing it on to others).
- For the most part, apply the above to all transitive dependencies.
That's all I can think of at the moment. All of the above are purposely hand wavy. Nothing is set in stone. Fundamentally, "weight" to me loosely translates to, "how much of a maintenance burden will I incur by using this crate?", and the above list are heuristics by which I judge that. Ultimately, that's what I care about at the end of the day, because I want to be careful with how I use my time. Namely, is the incurred maintenance burden outweighed by what the library does for me?
The best crates are the ones that incur zero or almost zero additional maintenance burden. I'm quite fond of using those. 
On other topics:
- Binary size is something I basically don't care about. I recognize that some people might, but it doesn't matter for the things I work on.
- I can't say I've ever really cared about the number of lines of code in a dependency. It might come up during my evaluation process if it's really gratuitous for the particular problem it's solving, but more often than not, I find that I've underestimated something if the LoC is higher than I expected. Interestingly, LoC might cause me to do the exact opposite of what you might expect. Namely, if a crate has a very small number of lines of code, I might decide to just solve that problem myself. In other words, I tend to avoid "micro" dependencies because they don't balance well with my particular set of preferences.
- Compile times are definitely a factor. They don't really impact maintenance time, but they certainly impact the time I need to wait until I can see my code run. I think if there were a way to characterize this signal, then it would probably be useful, but I must say that compile times thus far almost always lose. Namely, compile times are typically most severely impacted for large crates (including all transitive dependencies), and large crates tend to solve complex problems that I don't want to solve myself. Thus, I wait.