The original commit adding it to contrib anticipated moving parts of it into git proper:
For example, we previously discussed the idea of a "git big-clone" that does
much of what "scalar clone" is doing. This patch series is a step to make
such functionality exist in the Git code base while we simmer on what such a
"git big-clone" command-line interface would look like.
This is one of many possible ways to do this. Creating a 'git big-clone'
could lock Git into backwards compatibility concerns so it is necessary to
approach such an endeavor with caution.
Seems like now it is locked into backwards compatability concerns around including the scalar command.This approach feels... wrong.
I agree it seems quite strange that it's not a git subcommand now that it seems like it's been incorporated into the git core release. I'm not exactly sure of it's utility...seems kinda heavy weight to just be setting recommended configurations? I guess it does some background automation for fetching and gc?
[0] https://devblogs.microsoft.com/devops/introducing-scalar/
According to the email linked in your sibling, that's exactly why it's a separate command in /contrib and not integrated into git proper.
Remaining a seperate command rather than a subcommand is motivated by command line backwards compatibility for users of the c version from microsoft/git, but also for users of the older C# version.
If they did git-scalar then they would still need a contrib subfolder command wrapper executable (not just a script, as many users are on windows and rely on it being an executable, not just a bash script).