For example, in discrete math, you probably couldn't easily prove that square root of 2 is irrational. But once you've seen that proof, then the proof of the irrationality for square root of 3, and square root of 6, you begin to see patterns. In effect, the solution gives you a template, and you note what changes have to be made as you modify the value.
Occasionally, you want to see where the proof fails. For example, you know the square root of 4 is rational (it's 2). If you blindly apply the proof technique and show it's irrational, then you've just blindly applied a technique. You need to stare at the result to see if it makes sense.
One reason to study the implementaion of an N-1 MUX from smaller MUXes is to think about how to solve related MUX problems. As you learn to solve them, you should be encouraged to think of other variations of the problem.
Can you solve it using DeMUXes? How about encoders and decoders? How about adders? You may discover that the same variations that work with a MUX may not work with an encoder. That encoders are harder to generalize, or use different rules. You may wonder "why is that? why does it work differently?"
You may ask what it means to generalize an adder, or whether it makes sense.
In a sense, many of these problems are not really about dealing with hardware problems, it's about learning how to solve problems. Hardware just happens to be the problem domain. If you had majored in, say, mechanical engineering, you'd solve problems there. The techniques might be different, but nevertheless you'd be solving problems. A different problem domain, and possibly even a different bag of problem solving skills.
You study the implementation of different MUXes not necessarily because you'll become expert implementators of MUXes, but because studying the solutions helps you learn how to solve problems through generalization.
You always have to be careful solving in this approach. Sometimes the solution doesn't always make sense, and you have to keep that in mind.
Let's consider a sports analogy. Kickball is a game similar to baseball. There's two teams. There's a pitcher who rolls the ball to home base. There's a kicker (instead of a batter). The kicker kicks the ball, and runs to first base, the second, then third, and back to home.
The objective of the team who's in the outfield is to get the players "out". In kickball, one way to do this is to throw the ball at the player while the player is running between bases.
If the ball hits the player in midair, then the player is out.
Since kickball is based on baseball, a person who's never played baseball but has played kickball might assume that it's valid to throw the baseball at a player to get him out. If the ball hits the player, one might guess he's out.
However, this is NOT a rule in baseball. The reason is subtle. The ball in baseball is smaller and harder and can move a lot faster. This means the potential to be hurt is much greater. A ball can hit you in the head. It's true that this can happen in kickball, but it's harder to generate that kind of velocity.
What's the point? When people solve similar problems, there's a tendency to use the solution exactly the same in different situations (much like throwing the ball at a player in baseball). It may be that what worked in one situation does not work in another. Therefore, you must consider whether the answer makes sense.
For MUX problems, one way to see if it makes sense is to trace it out. Tracing doesn't always help, because if you were implementing a 1024-1 MUX, you may not be patient enough to do the traces.
Thus, you'd like to convince yourself of the mathematical correctness using some combination of mathematical reasoning and testing your hypothesis by using a few examples.
The more mathematical you are, the more likely you want to have precise definitions and precise rules of deductions, so you can deduce. The more intuitive you are, the more likely you will work through many examples, create hypothesis, and test the hypothesis (i.e., use scientific method). In some ways, these two approaches are opposite, which is interesting because math (which uses deduction) and science (which uses generalization and the scientific method) are so related.