Isn't blindly using InvokeRequired just bad practice?

You are taking things out of context here. The first question you linked linked another question which specifically was about writing a thread-safe method to access a UI control.

If you don't need a thread-safe access to a UI control, because you know you won't update it from another thread, then certainly, you shouldn't employ this technique. Simply update your UI control without using InvokeRequired or Invoke.

On the other hand, if the call will always originate in a thread other than the UI thread, simply use Invoke without first checking for InvokeRequired.

This leads to three simple rules:

1. If you update the control only from the UI thread, use neither InvokeRequired nor Invoke
2. If you update the control only from a thread other than the UI thread, use only Invoke.
3. If you update the control from both the UI thread and other threads, use Invoke in combination with InvokeRequired.

In practice people tend to call the same method from both the foreign and the owning thread. The usual pattern is that the method itself determines whether the thread is the owning thread. If it is, it executes the follow-up code. If it isn't the method calls its own self using Invoke this time.

One benefit of this is that it makes the code more compact, as you have one method related to the operation instead of two.

Another and probably more important benefit is that it reduces the chance that the cross thread exception will be raised. If both methods were available at any time and both threads could choose any of the two, then there would be a chance of a seemingly legitimate method call raising an exception. On the other hand, if there's only one method that adapts to the situation, it provides a safer interface.