It's newish (yes, 6 years is newish for projects that don't have a lot more hours, direction, and dedicated drive behind them than git-lfs seems to) and janky or unintuitive in some cases and adds another obtuse nerdy thing for e.g. artists to figure out (or be supported through) and requires extra software and server config to self-host (most of which is, uh, not as complete as one might hope) and makes backups less dead-simple than plain git and has nothing like an official server-side implementation (last I checked GH's "don't use this for production" implementation was the closest thing) and can make any kind of automation or extra tooling used with git a real pain since much of it's not lfs-aware, including some built-in git commands in certain situations (git-archive against a bare repo, for instance, which can be a super handy command in many situations).
Overall, I like it and have promoted its use and stand by that, but not every place has the time or inclination to screw around with it when they can just pay for something that solves the problem (likely Perforce).
While we're at it, git in general would be one fuck of a lot easier to support for cross-platform users and in tooling for complex projects if libgit2 caught up and took over as the official implementation. The pile-of-binaries-and-shell-and-god-knows-what-else (all living on top of a hacky, huge bundle of junk, on Windows) official Git itself is a huge impediment to doing anything with git other than just executing "git [command]" in Unixy environments. It'd also make "build my own GitHub" type projects far more tractable, cutting out some of GitHub's (and GitLab, et c.) server-side moat.
LFS is a pain, right now, even 6 years in, if you don't tie yourself to a major commercial Git host or put in a lot more effort than traditional self-hosting git requires. To reiterate: I still like and advocate it, circumstances allowing, but it definitely is not a mature solution.
I also think a lot of people in this thread don't understand that large companies don't want everyone having even read access to the entire repo.
Using a system like perforce, artists can drop files in the assets part of the repo, translators can have access to script files, and coders can have access to the parts of the code that they are working on.
Source code licenses are still a thing, where after buying a license only a certain # of people in a company are even allowed to view the licensed source code.
The way this is worked around is a build server exists where some pre-built libraries are pulled from during a developer's local machine build.
While I'm happy to no longer be working in that environment, it is unfortunate that many of the commenters cannot imagine an ecosystem different than their day to day. :/
Overall, I like it and have promoted its use and stand by that, but not every place has the time or inclination to screw around with it when they can just pay for something that solves the problem (likely Perforce).
While we're at it, git in general would be one fuck of a lot easier to support for cross-platform users and in tooling for complex projects if libgit2 caught up and took over as the official implementation. The pile-of-binaries-and-shell-and-god-knows-what-else (all living on top of a hacky, huge bundle of junk, on Windows) official Git itself is a huge impediment to doing anything with git other than just executing "git [command]" in Unixy environments. It'd also make "build my own GitHub" type projects far more tractable, cutting out some of GitHub's (and GitLab, et c.) server-side moat.
LFS is a pain, right now, even 6 years in, if you don't tie yourself to a major commercial Git host or put in a lot more effort than traditional self-hosting git requires. To reiterate: I still like and advocate it, circumstances allowing, but it definitely is not a mature solution.