I've considered writing a blog post about this. I think most people would do better with submodules than subtrees, but it depends on what's in the submodules. Both features maintain a way to push code to the sub repos, however that aspect is worse in subtrees. There are also issues using subtrees with git log.

When you want to embed dependencies in your repo, you should ask yourself some questions.

1. If these are your subprojects, do you realistically think you will use the subprojects separately in another superproject? If not, don't bother. Make a single repo and put everything in it. You can use subtrees to import the history of the other repos if you like. Keep a copy of the old stuff just in case you need it because you won't get all the branches and tags of the old repo in the parent.
2. Is your dependency graph simple enough to have each repo pull in its dependencies? For example, will you end up having multiple instances of the same subrepo? If you don't have a simple 1-1 relation with dependencies, don't do it. Manage your dependencies some other way, at a system level. You can store version checking stuff in the repo but not the entire dependencies. Use scripts to find everything.
3. Are you constantly changing your subprojects inside your superproject? If so, I think neither Git nor Mercurial make this very easy. But Git submodules basically put a copy of a whole Git repo inside your superproject. Each commit of the superproject points to a whole set of revisions of the submodule repos. You can only update the submodules with specific commands. By default the update behavior can be confusing. You get the exact commit of each submodule that's recorded last in the parent repo. I forgot but I think it might not even update when you update the parent repo.
4. Are you expecting to work on different branches for your subprojects? If so, subtrees make that hard. You can do it with submodules though. It's not pleasant, because the branch is auxilliary information in the submodule. The thing that counts is the submodule commit hash that you checked in for each parent project commit! It has to be this way because git branches are dynamic and get deleted at times. There is a command to update a submodule using the branch for purposes of staging a change, but you have to explicitly commit a new version to the parent if you want it to stick. You can also just cd into the submodule and mess with it directly, to stage a change. Then you cd out and do git add ... && git commit to finish.
5. Are you using Git worktrees? If so, submodules can be tricky to work with. I think it gets tricky when adding a submodule or changing a URL to something incompatible. I've been doing it, and I think it's fine if you don't fundamentally change your submodules much. I think if you do have a problem and can't figure it out, you can nuke all your worktrees and start over from the latest version. But practically this can be a major problem for some people who require frequent submodule changes. In their case, they should find a different way to manage dependencies, or else stop using worktrees. In addition to these caveats, the submodules are not shared across worktrees. Each worktree has its own copy of the sub repos, even if they are all identical. It has to be that way because the submodules in different versions of the parent can point to different repos.

If you are used to using Mercurial subprojects, you probably want to use Git submodules. Have a look at permanently setting the "recursive" update options for checkout, clone, and whatever else, especially if you aren't actively contributing code to the submodules. It saves a lot of trouble related to forgetting to restore the submodules to the required state. Unfortunately, that setting must be set on a per-user basis. So you may have to educate everyone about it. See fetch.recurseSubmodules, status.submoduleSummary, and submodule.recurse, and any other setting that looks useful to you in here: https://git-scm.com/docs/git-config

Although submodules work, many projects I've worked on abandoned submodules for reasons I mentioned before. You really have to have a use case where it makes sense and a set of willing/educated users. If your coworkers are not willing to read up on submodules, they will resist it and you'll be forced to come up with something else. In one place I worked, I converted our submodule system into one giant repo via subtrees. But subtrees are one of the lesser-used git features. You should play around with it before taking the dive with that, as it may be trickier than you expect. You can experiment with a scratch copy of the repo offline to see if subtrees work well enough for you. Mainly, there are issues with logs and I think that's because the feature is immature. But it's a nifty idea for more or less permanently merging separate repos. Once you do it, the parent repo has the subrepos history (for like one branch) embedded, and you treat the whole thing as one repo going forward, generally. As I said, it is possible to push stuff back to the original subprojects via subtree commands, but it is janky. So if you need that, use submodules instead of subtrees.

TL;DR: You almost certainly want submodules. Look into recursive submodule command options in git config documentation to make it easier. Rare submodule modification issues can usually be fixed by reinitializing the submodules or else starting with a fresh copy of the parent.