a) Your controller should be relatively simple. If it is buggy/broken it should be immediately obvious when the app is run. So, not being able to unit test it separately is not a big a deal, I think[0].
b) I don't think having the view and controller coupled makes this a big deal in a lot of cases[0] as long as the controller doesn't have behavior creep.
Isn't the controller where your bussines rules are encoded? It is probably the more complex part of your app, and it's complexity is driven by business decisions and not technical ones. Unless you mean something different by controller(very possible, it is a very overloaded term), I don't think your premises are very sound.
I think this gets to the heart of this discussion. Since the term 'controller' is so vague everybody has a different understanding.
In iOS development there are UIViewControllers which are very tightly coupled to the UI, but are often misused to handle business logic.
With MVVM you essentially treat them as views and extract everything that is not exclusively related to visual presentation.
I see the controller as an objects whose purpose is to shuttle data back and forth between the view and the model. The business rules should be in the model. the controller can do some very minor formatting type things, handle events, etc. but no business rules.
Basically, the View is presentation, the Controller is interaction and the Model is logic and data.
Yeah, in that case I agree with you. Under that definition M-VC just means to separate your business rules from your UI, which is always a wise move. I do think the interesting part that is missing is how you organize everything that isn't UI, but I guess that's a topic for another discusion.
b) I don't think having the view and controller coupled makes this a big deal in a lot of cases[0] as long as the controller doesn't have behavior creep.
[0] There are exceptions to everything.