I am on the "support everything" side. You see, many times a user wants support, he does not need a technical solution so much as he needs somebody to hold his hand and tell him that everything will be OK.
Promising support is a factor in user satisfaction, even if people never happen to use it - they just feel better knowing that, if they need help, there is somebody to give it. And then, if a problem happens: When somebody is upset at your application not functioning the way he expects, having a fellow human say "I understand your problem" and sincerely try to work on a solution will calm him several notches and even completely defuse the situation in the lighter cases. Don't forget that while unmet expectations are the main cause of dissatisfaction, equity, or the feeling of being treated fairly, also has an influence. Being heard is one of the three requirements for experiencing procedural fairness, and if it is not possible when the user feels that he has something to say, he will feel unfairly treated and build a negative attitude towards your application, in the worst case resulting in losing him and getting bad word of mouth from him.
When you offer live chat to anybody with a problem, you are sending the signal, "We are here for you, and will help you". When you restrict live chat to "these areas only", you send the signal "your request has to fulfill your criteria before we even consider helping you". This sounds uppity even in the best case, and it is certainly not how you treat a customer who is already upset because he has a problem with your application. You have probably seen how users, especially new users, react here on StackExchange when their question gets closed for being off-topic. This is exactly how your users will feel if you tell them "sorry, we don't provide support for this problem". Stack Exchange can deal with the fact that most of these people turn their back and never visit the site again; in your case, they will be people who have already paid money for your product, and you can't afford alienating them.
Users will still perceive the creation of a two-class-society, the ones who get help, and the ones who don't, if they are in control of who is getting help. For example, premium plans with added support work well. So if the reason why you want to limit your support availability because you are afraid you don't have the resources to support everybody, it might be the better decision than denying support to people who had the bad luck to experience an issue you are not offering support for - it may sound like a perfectly reasonable business decision, but is not something the user will understand or care about.