Constraints Are Not The Answer To Every Problem

We use constraints a whooooooole lot in rigging, don't we?
They're a no nonsense catch-all solution for when you just want an object to follow another object. Don't care about its hierarchy or none of that, I just want it to follow! Why all these questions? I just want life to be simple!

Well fine. But need I remind you, we are riggers. "Simple" was never in our future.

You may have heard people online saying "Ew! Constraints! Don't use constraints! Constraints are terrible!" So let me fill you in on what they're talking about.
Look at your average constraint in the node editor:

That's an awful not of connections. And that's just a vanilla constraint - once you start messing around with multiple targets, the number of connections increases. Constraints are a nuclear solution to a surgical problem. They take in all kinds of information from the driver object(s) and driven object to make sure that there are a very few curve balls one can throw at it. Every single connection in a network adds a little extra to a rig's evaluation time (how quickly Maya runs and responds when the animator is using the rig). So it's because of all these connections that people say constraints are "slow" or "heavy.

But in most situations a lot of these connections are not needed and therefor wasteful. They exist to deal with twisty mathematical scenarios that you can simply plan around by building your rig cleanly and deliberately.

Let me back up clarify I am NOT saying that constraints are the devil and you should never use them. Constraints have some advantages. Mainly that they're quick to set up, and quick to make adjustments to later on. And in an industry environment that's worth a lot. Both because it saves time and because everybody understands constraints, so somebody else who has to work on your rig later can have an easier time understanding what you've gone and done.

I use constraints every day when I'm trying to hammer out something quickly.

But if I'm taking the time to methodically construct something important, that I know I'll get a lot of use out of so I want to get it as close to perfect as I can, and especially if it's a very big complex system that could get very heavy very quickly - that's when I'd make an effort to use other, lighter solutions over constraints.

So really the only knock against constraints is that they [can be] heavy (and I guess they do also look ugly in your Outliner.)
But a simple prop rig with maybe a dozen or so constraints? That's not a big deal.
A complex full character rig, complete with facials, on the other hand could easily require hundreds of constraints, and that shit adds up, my friend.

So let's talk about the alternatives:

Parentage:

The most ideal scenario is when you can make an object follow another by simply parenting them together. Duh. That way any transformation done to the parent is inherited by the child.
This is so obvious I wouldn't bother point it out - if we're even in this situation it's probably because we're already in a place where parentage isn't an option.
But it's worth considering when planning your rig hierarchy. It's why I prefer a hierarchy where controls and joints can intermingle in the same hierarchy, rather than separate controls and joints groups - because a lot extra nodes and connections can be saved when a control in an FK system drives a joint simply by virtue of that joint being its child.

Direct Connection:

So parentage is ideal, but when that's not an option the next best thing in terms of evaluation times is direct connection.
I have encountered situations like this before (hell, I've made situations like this before I knew better):

Assuming that yes it is necessary to keep the joints and controls out of eachother's hierarchy for some reason (there are reasons. It happens) why on earth would you burn up precious computation with constraints? If the joints just have to follow what controls are doing, why not just plug the controls' transform attribute outputs directly into the joints?
Remember that: For a direct connection workflow such as this, the control hierarchy and the joint hierarchy have to match.

The reason direct connections are so computationally efficient is because rather than having to evaluate what the control is doing AND what the joint is doing, Maya can just evaluate the control and then say "I don't need to think about the joint. Whatever I worked out for the control I can just throw to the joint as well".
There's no math node in the middle, no constraint, no extra work that needs to be performed to figure out what a control transformation should mean for the joint, they both just move as one. A teeny tiny bit of memory needs to be reserved for the connection itself, otherwise, it's basically free.

Matrix Based Constraint:

Okay, this here will serve you will your entire rigging career, so it deserves a post all to itself:

https://rigjuice.blogspot.com/2021/08/matrix-constraint.html