Steps to constrain a design

I wouldn't say it's a tool issue, as that's how SDC constraints are defined and all SDC compliant tools behave that way. I don't know the reason, but I would guess this behavior is to keep with the mantra of behaving as conservatively as possible. By adding a setup multicycle of 2 to a path, saying the setup should be analyzed to the next latch edge, the hold edge is still the most restrictive one. This is the correct analysis when you're not running data at a rate slower than the clock rate, but just transferring data at the full rate between phase-shifted clocks. So in many cases adding a multicycle -setup of 2 without adding a hold multicycle is what the designer wants.

One way to think of it is that the multicycle -setup changes which window you're aiming for, but not the data rate. For example, if your launch and latch clocks are edge-aligned 10ns clocks, then the default setup latch edge is at 10ns and the default hold latch edge is at 0ns. The data rate is the difference of these, i.e. 10ns. If you add a multicycle setup of 2, then your setup latch edge is at 20ns and the hold latch edge is at 10ns. You're still transferring data through a 10ns window and can run at the same rate, you just happen to be shooting for the next window. Doing other multicycle -setup values, say 3 or 0, just change which window you're aiming for, but it's always a 10ns window. When you add a multicycle -hold, it changes the size of the window. So back to our multicycle -setup of 2, if you then add a multicycle -hold of 1, your setup latch edge is at 20ns and hold latch edge is at 0ns, resulting in a 20ns data window, so you're running at half the rate. This may not be the technical definition, but it generally holds true. (If the clocks are funky periods, duty cycles with rise-fall, it may not be quite that simple, but I haven't looked into it since that seldom happens)