FSM modeling when outputs are not simple functions of input and current states
The next state and output calculation is not straight forward. If I keep adding signals like data/control signals, these dependencies will increase.


Well, that is a typical problem. 


  or a case such as this, is it still recommended that we follow 2/3 process block FSM and remove all the extraneous logic(Ex : the reset counter) from the module where FSM is coded?


Well, you didn't really write a FSM if there's external factors that aren't actually input that change states. You'd want to integrate these timers in the FSM, so that it's logically self-contained – and can be tested as such.

The problem really is that it's usually pretty hard to reason about what your design does if you don't keep your state machines clean. 

"Extra Effort" is usually worth it if it means that you can still understand your design in a week or a year. Most code is "write once, read many times", and keeping your state machine cleaner (even if that means investing more in formalism) is usually a good idea – all the commercial projects I've worked with that did hardware design had a clear review process, and the ability of a reviewer to quickly grasp what you're doing is not "a good thing", but a requirement for your code being accepted!

What's even more important: it's super easy to screw these things up. Keeping separation as far as possible between system components makes this easier for you, in the long run. The little extra "mechanical" effort will mean nothing.

I see these kind of approaches in a lot of beginner coders for any language, by the way: Because they feel that the writing code part is the hard one, they try to reduce the code in favor of taking seemingly elegant shortcuts. As soon as they're more used to their language and tools, they come back and regret what they've done – not the writing of code is the hard part, the designing a correct system is hard. And system design is easier for humans with patterns they understand.