There are two ways to solve this:
1. Write and distribute a wrapper script that sets up the clone in the way you want, with hooks, diff tools, LFS, etc.
If you're talking about diff tools and LFS, you need some way to actually install those components, so presumably it shouldn't be hard to get this wrapper script onto end user machines.
My employer uses this and it works well - we have a special command that creates a new clone and configures it appropriately. Once you have a clone, you can use the git commands as usual. People seem fine with this workflow. (Previously the special command was named something like "git-xyzclone" so you could just run "git xyzclone" instead of "git clone". But as we added a few more build/review/release features, we made a general "xyzdev" command with a few subcommands, of which "clone" is one.)
2. Set up /etc/gitconfig (or ~/.gitconfig) and in particular the init.templateDir setting to customize the settings you need.
Again, presumably you have some way to install things - but if you don't, tell employees to run "curl -O https://corp.example.com/.gitconfig" as part of setup, and then you can bootstrap yourself from there.
Git doesn't and cannot accept executable hooks/LFS helpers/etc. from an arbitrary remote server because then as soon as one of your employees clones something from GitHub they'll get event-stream'd. Your authority to enforce configuration comes from your authority (either technical or social) to get employees to install things on their machines - if you have that authority, then there are multiple ways to accomplish this.
(I suppose Git could have a "core.executeArbitraryCodeFrom=https://git.example.com" setting or something, but if you have the ability to push out that setting to all your users, you have the ability to push the actual settings you want.)