Vote "agree" if you think Arbital should enforce the first letter of a page title to always be capital.
Visual consistency is very important, and makes the website look professional. If some titles are capitalized and others aren't, this leads to inconsistent look and feel.
One argument for allowing different casing is that the author's choice can signal to the reader how important this page / concept is. However, there is some risk that many users will not understand that this signaling is done on purpose, and will instead think that it's a mistake.
Simplicty is a virtue. Arbital is already a pretty complicated platform, and there are a lot of existing Style guidelines, so adding another rule, unless it's beneficial, is actively detrimental.
Furthermore, since the pages often belong to the community, having flexible casing might cause inconsistency and disagreement about it. To prevent that, the rule governing which one to pick should be crisp and somewhat objective, which seems hard to do in this case.
The difference between lowercase and uppercase may carry semantic information in some fields. Nothing is coming to mind off the top of my head, but Wikipedia has the {{lowercase title}} tag for a reason.
I have an instinctive sense of how propernouny a term is, and I instinctively try to title pages in a way that reflects this sense. Even if this is hard to get right, it doesn't have to be gotten right on the first try, because in Arbital it's much easier to edit titles without breaking things compared to Wikis.
Other users may have their own senses of what a lowercase title means. While the global Arbital namespace probably ought to follow only one main convention, people creating local wiki-style pages and tags around their blogs should certainly be able to title things in lowercase, so we'll at least want the technology to support that much.
In general, conventions are constraints and it's wise to be cautious about how you restrain your users. Things that cause general damage, yes, restrain those. Prettification is a much more tenuous territory, because the very act of trying to impose your convention means that you and the user are disagreeing about what's pretty, and you're going ahead and other-optimizing them in the belief or rather hope that most people will see it your way rather than their way; and the Typical Mind Fallacy is a hazard here.
In general, the burden of proof should be against adding constraints to the user. This is true if there's no way to accomplish the same goal by behavior shaping or incentives - the very fact that you can't think of a way to incentivize something is itself often an indicator of something wrong.
We can always go back and change the convention later if that starts looking like a good idea.