The output you're showing indicates that LFS is configured, as you say, such that it should be tracking the file in question.
However, it looks like this configuration was set up after the file had already been added to the repo, and so this specific file is not under LFS control. LFS knows that it's supposed to manage the file at that path, but it sees the original file (rather than a pointer) actually referenced in the repo at that path, hence the Encountered 1 file(s) that should've been pointers, but weren't.
Most likely the git commands themselves would have performed their expected tasks[1], but you also get these warnings to tell you that LFS cannot do its job as things stand right now.
You can fix this "going forward" pretty easily.
git rm --cached Dependencies/BSI/Debug/64/TFC80NET.dll
git add Dependencies/BSI/Debug/64/TFC80NET.dll
This will cause the file to be re-staged and, as it is restaged, the LFS "clean" filter will shuffle it off into the LFS repo and replace it in the index with a pointer file.
You could commit that change, and then operations from that commit forward would not get the above warnings, and no new versions of the large file would be committed directly into the core repo. (That might or might not really matter, depending on whether this .dll ever changes. It's the bare minimum value you could potentially get from LFS.)
But what that won't do: it won't remove any existing version(s) of the .dll from the core repo. That means the bloat that's already there, will still be there. People cloning the repo will still be saddled with the cost of downloading those historically-referenced versions.
If you want to fully benefit from LFS, that would be the point of doing a history rewrite, be it with the "lfs migrate" tool, or the lfs mode of the BFG Repo Cleaner, or a custom filter-branch script. Each of these has its own issues and pitfalls, so you'd want to read up on what's involved.
What all such techniques have in common is, they are sweeping history rewrites, which will invalidate all existing clones of the repo (as well as any tooling or documentations that might depend on specific commit ID values). So it's necessary to coordinate with everyone using a repo before doing such a rewrite. (A reasonable practice is to have everyone push all changes to origin - even if not in a fully-merged state; and then have everyone discard their local clones; and then do the rewrite; and then have everyone re-clone from the newly-cleaned repo.)
[1] If you dig deeper and find that the reset and checkout commands did not revert the file in the index and work tree, then there may be additional issues to address.
