First, to assuage your fears: named branches have been in Mercurial since the beginning, and are actively used by the Mercurial and TortoiseHg teams for developing Mercurial and TortoiseHg, so they're well-supported and not going anywhere. If you keep using named branches, you're certainly "safe," from a stability and support standpoint.
Now, to elaborate on Jason's answer:
There are two reasons that people generally stay away from Mercurial's named branches: they're "permanent", and they break a lot of workflows in older versions of Mercurial.
By saying that named branches in Mercurial are permanent, I mean that they are always in the revision history. In Mercurial, when you make a commit on a branch and push it, that commit is part of the repository's history forever. What a lot of people wanted with Mercurial branches were throw-away branches that wouldn't show up in the history once they were done, and that you could just obliterate if the experiment failed. If your branch is a clone to somewhere else on disk (or a Kiln branch repository), you can just delete it if you decide you don't like it, and it won't clutter up your history or make your repository bigger. If it's a named branch, it's going to be there, even if you decide never to merge it. That's why Mercurial itself encourages named branches for long-running branches, but discourages their use for feature branches. It's a social, not technical, reason.
These social problems are technical problems in earlier versions of Mercurial, though.
In older versions of Mercurial, using named branches breaks a lot of common Mercurial behaviors. Talking about the
tip changeset stops making sense; on older versions of Mercurial,
hg fetch and
hg merge would suddenly always require explicit arguments on what you wanted them to do; and commands like
hg up with no arguments became dangerous, happily jumping around branches without warning.
Over the last year or so, the Mercurial team has made a huge number of improvements to named branches. You can close branches without merging them,
hg up will go the head of the current branch,
hg merge will default to merging heads within a branch (rather than demanding explicit parameters 100% of the time), and so on. Working with named branches now generally does not cause any problems.
For Kiln, we still discourage using named branches because older versions of Mercurial do not handle them well, because we think that branch repositories and local clones are an easier-to-grasp concept, and because they work for most people (i.e., people who do not work routinely with multi-gigabyte repositories). As long as you don't have truly massive repositories or don't clone locally often, then Kiln's Activity Feed, push histories, "Outgoing" tab, and similar features, give you easy, rich monitoring of all commits in a project across repositories, without the mental overhead of named branches, and without any concerns for users on older versions of Mercurial.
If you understand how named branches work, understand the issues involved, and you want to use them, then go ahead. Mercurial and Kiln both fully support them and will continue to do so, and we have some good ideas on how we can make Kiln handle them better in upcoming versions (such as filtering by branch, and pushing branches in a reasonable way for server-side push). But we still think that branch repositories are a better solution for most users of Kiln.