Git LFS pointer storage vs standard Git objects for portable local mirrors

A design decision is needed for a repository that contains large binary assets and must balance local disk footprint against full portability.

Standard Git object storage keeps every byte of a binary in the packfile history, which preserves a self-contained repository that can be archived and checked out offline without external dependencies. Git LFS replaces large files with text pointers in the main repository and stores the actual binary data on a separate LFS server, reducing the size of the initial clone and the local working tree footprint.

The constraint is a requirement for a fully self-contained local mirror that remains usable offline, while also limiting local disk usage for multiple versions of large binaries. The trade-off is between repository portability as a single source of truth and the performance and footprint benefits of offloading binaries.

With Git 2.x and an LFS client available, does a repository using LFS pointers satisfy the portability definition of standard Git object storage for offline archival? How does the local disk footprint compare when retaining multiple historical versions of the same large binary under each approach?