I suspect it's an internal decision by WRI to allow as variables only expressions of the form A[0, 1, 2], that is, a symbol with integer arguments. You could try reporting your desired functionality to WRI; maybe they will extend what expressions are allowed. Instead of being localized in the usual way, the expressions are remapped to Unique[] symbols. For instance, the expression A[0] would be mapped to a symbol like $101. In this scheme, almost any expression could be allowed as a variable, because it can be replaced by a valid variable name. One danger is that in an expression like V[1, T], the symbol T would not be localized, so if T changed value, one should expect a change in behavior. One could wish that V[0, T] were mapped to $102, but that would remove the dependency on T. From a programming point of view, this would be really bad. But if T in a user's program is an inert symbol, then from the user's point of view, it is a bit irritating not to be able to do it.
Well, with some hacking, you could do it like you want, but let me first suggest this:
Manipulate[{A[0], V1T}, {A[0], 0, 1}, {{V1T, 0, HoldForm@V[1, T]}, 0, 1}]

Hack:
The check on what is a valid variable is performed Manipulate`Dump`extendedVariable. You can add your own allowed forms like this:
Internal`InheritedBlock[{Manipulate`Dump`extendedVariable},
Manipulate`Dump`extendedVariable[_Symbol[__]] := True;
Manipulate[{A[0], V[1, T]}, {A[0], 0, 1}, {V[1, T], 0, 1}]
]

This would be a little safer, but I would still recommend the first approach above:
Internal`InheritedBlock[{Manipulate`Dump`extendedVariable},
Manipulate`Dump`extendedVariable[_Symbol[(_Integer | _String) ..]] := True;
Manipulate[{A[0], V[1, "T"]}, {A[0], 0, 1}, {V[1, "T"], 0, 1}]
]
Bug/Restriction (updated):
My point seemed to be lost in the simple example I originally gave, so I have changed it and added some explanation to try to clarify the issues. My claim was and is: I'm not sure why forms like A[0] are allowed. They don't work the way they do in normal Mathematica.
The point is that when expressions A[0] etc. are replaced by Unique[] symbols like $123, only the literal expressions like A[0] etc. are replaced in the Manipulate code by kernel, before the Manipulate is sent back to the front end for instantiation. An expression like A[n] that evaluates to A[0] at runtime will not be linked to the actual variable $123 being used to represent A[0].
Manipulate[{A[0], A[n]}, {A[0], 0, 1}, {n, 0, 1, 1}] // InputForm
(*
Manipulate[{$3340, A[n]}, (*$*)
{{$3340, 0, RawBoxes[RowBox[{"A", "[", "0", "]"}]]}, 0, 1}, (*$*)
{n, 0, 1, 1}]
*)

A more complicated example, which might illustrate better a more practical use of A[n], is given below. But simplicity has advantages in an issue that is complicated and potentially confusing.
One reason for using variables like A[0], A[1], etc. is to be able to parametrize them by A[n]. Such functionality can often be accomplished with lists, which can be made to work in Manipulate, but that seems a separate issue. Workarounds are not an explanation. My point is that one of the basic uses of A[0] etc. cannot be implemented in Manipulate.
A more complicated example:
Manipulate[
With[{f = Sum[A[n] x^n, {n, 0, m}]},
Plot[f, {x, -1, 1}, PlotLabel -> f]
],
{A[0], 0, 1}, {A[1], 0, 1}, {A[2], 0, 1},
{m, 0, 2, 1}]

Note that A[1], A[2], and A[3] in the list are not updated or connected to the controls. (This is because, while A[1] is remapped to $nnn, the expression A[n] is not!) My advice is to avoid them, and use
{{A0, 0, HoldForm@A[0]}, 0, 1}
instead.
A workaround for the last example, for those who like them:
Manipulate[
With[{f = Sum[A[n] x^n, {n, 0, m}] /. {A[n_] /; n == 0 :> A[0],
A[n_] /; n == 1 :> A[1], A[n_] /; n == 2 :> A[2]}},
Plot[f, {x, -1, 1}, PlotLabel -> f]
],
{A[0], 0, 1}, {A[1], 0, 1}, {A[2], 0, 1},
{m, 0, 2, 1}]

The literal occurrences of A[0], A[1] and A[2] in the replacement rules are
replaced by unique $nnn in the kernel:
{A[n_] /; n == 0 :> A[0], A[n_] /; n == 1 :> A[1], A[n_] /; n == 2 :> A[2]}}
At runtime the rules replace the evaluated A[n] by the corresponding $nnn variable. Such a set of rules has to be applied at all appropriate places in the code. For instance it cannot be applied to the whole body, because it has to be applied to f before Plot is evaluated. In a complicated piece of code, it would be a big pain. In such an application, it would be best to avoid them. After all, that is basically what Manipulate is doing already by rewriting them as simple variables (original example):
Manipulate[
Table[A[n], {n, 3}],
{A[1], 0, 1}, {A[2], 0, 1}, {A[3], 0, 1}] // InputForm
(*
Manipulate[Table[A[n], {n, 3}],
{{$3335, 0, RawBoxes[RowBox[{"A", "[", "1", "]"}]]}, 0, 1},
{{$3336, 0, RawBoxes[RowBox[{"A", "[", "2", "]"}]]}, 0, 1},
{{$3337, 0, RawBoxes[RowBox[{"A", "[", "3", "]"}]]}, 0, 1}]
*)
TableofA[n]seems like it's about evaluation order more than things likeA[0]being allowed. It works fine withEvaluate:Manipulate[Evaluate[Table[A[n], {n, 3}]], {A[1], 0, 1}, {A[2], 0, 1}, {A[3], 0, 1}]. While this fails in the same way, unless there is an evaluate:listOfVars = {x, y, z};Manipulate[(*Evaluate@*) listOfVars, {x, 0, 1}, {y, 0, 1}, {z, 0, 1}]– Seth Feb 18 '16 at 03:47Manipulateparameter, e.g.Sum[A[n], {n, m}]? Plus, you can hardly program an arbitraryManipulateunder the assumption that the body will be evaluated before the variables are localized. Your second example seems quite a different situation, since it depends on a global variable, unlike theTablecommand. – Michael E2 Feb 18 '16 at 04:00Manipulate[Plot[Sum[A[n] x^n, {n, 0, m}], {x, -1, 1}], {A[0], 0, 1}, {A[1], 0, 1}, {A[2], 0, 1}, {m, 0, 2, 1}]. -- And here's a fix based on my analysis:Manipulate[Plot[Sum[A[n] x^n, {n, 0, m}] /. {A[n_] /; n == 0 :> A[0], A[n_] /; n == 1 :> A[1], A[n_] /; n == 2 :> A[2]}, {x, -1, 1}], {A[0], 0, 1}, {A[1], 0, 1}, {A[2], 0, 1}, {m, 0, 2, 1}]– Michael E2 Feb 18 '16 at 04:06Tableexample is:Manipulate[Evaluate @ Table[A[n], {n, 3}], {A[1], 0, 1}, {A[2], 0, 1}, {A[3], 0, 1}]– m_goldberg Feb 18 '16 at 06:00listOfVarsexample without a global variable:Manipulate[ Evaluate@(ToExpression /@ Table[letter, {letter, {"x", "y", "z"}}] ) , {x, 0, 1}, {y, 0, 1}, {z, 0, 1}]. Again,Evaluatedoes the trick, making the symbolsx,y,zvisible toManipulate. – Seth Feb 18 '16 at 08:22Evaluate). I couldn't figure out a way to make yourSum[A[n]…]example work without your clever pattern-replacement trick. Just out of curiosity, is there any way to do your trick without writing it out for each value ofn? I tried several things but no dice. – Seth Feb 18 '16 at 08:23A[0]is accomplished effectively bynewvar = Unique[]; body /. A[0] -> newvar, so only literally occurring expressionsA[0]are replaced. Expressions likeA[n]that evaluate toA[0]only at runtime have to be manually replaced. See for instanceManipulate[{A[0], A[n]}, {A[0], 0, 1}, {n, 0, 1, 1}] // InputForm. – Michael E2 Feb 18 '16 at 11:23Evaluatetrick helps to expand things so the literal termsA[1]etc. are visible toManipulate, but in cases where it doesn't make sense to prependEvaluate@to the whole code, it may not be run in the desired order. – Seth Feb 18 '16 at 20:44