Our team has experimented with git submodules for some core CRUD functionality shared by most of our products. We have also successfully used Nuget packages (self-hosted now) f
I prefer using submodules over Nuget packages for frequently changing internal libraries. Here's why:
Merging: If several developers make changes to the same library at the same time, with submodules, these changes can be merged. With Nuget packages, obviously there's no concept of merging.
Less wait: With submodules, you push, and then pull with whatever repo you need to use the submodule in. Usually a few seconds. With Nuget you must wait for the package to be be published, typically after your CI process completes.
Versioning clashes: Again, if several developers make concurrent changes, they may increment the Nuget version # to the same one, despite their changes being different. How much of a pain this is to address depends on your CI process.
Can make changes in "client" repos: Sometimes it's easiest to flesh out the details of library changes while working on client code that will use the library. With submodules, this is possible. Of course, this is no substitude for test coverage.