Use grep package -F '[['package Cargo.lock | wc -l instead. This is doubly true if you pull in multiple crates using the same framework behind it, e.g. in async projects. E.g. for exa this is 45 instead of 61. For deno this turns into a 3x difference (515 vs. 1571).

Other reasons, besides what has been mentioned (vendoring being very uncommon, crates existing for common type and trait definitions, crates being generally scoped more narrowly resulting in more smaller crates), a lot of crates have additional crates for macros. Bindings often end up being a whole bunch of crates for this reason (i.e. one xyz-sys crate for the FFI bindings, plus one or more crates for a rusty wrapper and perhaps one or more crates for convenience crates). Case in point from deno's dependency tree:

    ├── futures v0.3.21
    │   ├── futures-channel v0.3.21
    │   │   ├── futures-core v0.3.21
    │   │   └── futures-sink v0.3.21
    │   ├── futures-core v0.3.21
    │   ├── futures-executor v0.3.21
    │   │   ├── futures-core v0.3.21
    │   │   ├── futures-task v0.3.21
    │   │   └── futures-util v0.3.21
    │   │       ├── futures-channel v0.3.21 (*)
    │   │       ├── futures-core v0.3.21
    │   │       ├── futures-io v0.3.21
    │   │       ├── futures-macro v0.3.21 (proc-macro)
    │   │       │   ├── proc-macro2 v1.0.38 (*)
    │   │       │   ├── quote v1.0.18 (*)
    │   │       │   └── syn v1.0.93 (*)
    │   │       ├── futures-sink v0.3.21
    │   │       ├── futures-task v0.3.21
    │   │       ├── memchr v2.5.0
    │   │       ├── pin-project-lite v0.2.9
    │   │       ├── pin-utils v0.1.0
    │   │       └── slab v0.4.6
    │   ├── futures-io v0.3.21
    │   ├── futures-sink v0.3.21
    │   ├── futures-task v0.3.21
    │   └── futures-util v0.3.21 (*)