Supporting a product that is customized for multiple customers is not a version control problem. It is a design and distribution problem.
Maintaining multiple code bases is a real pain. It's bad enough to need to duplicate the code base to support multiple platforms and languages, let alone multiple customers. Better instead to build a modular product. Sure, there will be elements that will require a larger degree of customization, and a small percentage of overlap where the code may need to be effectively duplicated, but it is better to create a very finely grained modular system design to cope, instead of attempting to branch where the risk is that the branches may become so divergent as to never be able to merge.
I myself work on an API that presently supports 3 hardware platforms, and greater than 3 customers. At the minimum, we would need to manage 9 separate code-bases if our code was not designed to be modular from the start. When I first arrived at the company nearly 10 years ago, the existing code base used conditional compiler directives to deal with 3 variants on a single platform, was about 50 times smaller than the present API incarnation, and took twice the effort to maintain. It took a lot of work, but we now have a product that never needs to be branched, and will be able to support literally any number of clients, platforms, and customizations.
So to specifically answer your question, It is better to maintain a single main branch provided you implement a design that will support a more modular development approach, and if your customization is required to be unavailable to more than a single customer, then you solve the problem in the way that your modules are accessed by your code, and in how they are deployed.