I read that whole article, and aside from an unsourced statement that GitHub et al will need “new and distinct servers” exactly zero of that seemed to support the thesis that a SHA-256 default was going to be “expensive”.
Submodules are not the preferred way to incorporate third-party code for any environment I know. And while web-exposed URLs for management tools like Jira or AzureDevOps will need to adapt before the new default can be used, doing so even with a wholesale re-hashing of every commit isn’t technically difficult.
What would be terrible and dangerous would be if git 3.0 entirely dropped SHA-1 support. But just as you’re free to keep on using “master” instead of “main”, i expect that extant projects will still be supported until a version after every major project has converted to SHA-256 or what have you.
Further reading that casts doubt on even submodules breaking:
https://www.deployhq.com/blog/git-3-0-on-the-horizon-what-git-users-need-to-know-about-the-next-major-release
It sounds like the new default is specifically to push GitHub et al to support SHA-256. Which they either will, or they will fork git and continue on with SHA-1 forever.