\newcommand{\iitthesis@thesisdatafield}[2]{%
\@namedef{iitthesis@#1}{#2}}
With
\iitthesis@thesisdatafield{authorEnglish}{Name of Author}
you'd define \iitthesis@authorEnglish to expand to "Name of Author", that is, you'd have issued the equivalent of
\def\iitthesis@authorEnglish{Name of Author}
This wouldn't check for the defined command to be previously undefined. If you want also this check, do
\newcommand{\iitthesis@thesisdatafield}[2]{%
\expandafter\@ifdefinable\csname iitthesis@#1\endcsname
{\@namedef{iitthesis@#1}{#2}}}
but for internal commands this isn't usually done.
In your motivation I don't see any need of defining the new command with an argument. If you need also to define a user level command, you can do with the same technique:
\newcommand{\iitthesis@thesisdatafield}[1]{%
\long\@namedef{#1}##1{\@namedef{iitthesis@#1}{##1}}}
In this case saying
\iitthesis@thesisdatafield{authorEnglish}
would define the command \authorEnglish so that if the user types
\authorEnglish{A. U. Thor}
the effect would be as if doing
\def\iitthesis@authorEnglish{A. U. Thor}
The \long prefix to \@namedef causes \long\def to be executed, so the argument can span one or more paragraphs.
This technique is employed by the LaTeX kernel, where \author{A. U. Thor} actually defines \@author expanding eventually to "A. U. Thor".
There are a few reasons why defining document commands has always been done using the control sequence for the command (\foo) rather than the control sequence name (foo). Of course, some of this comes down to 'you'd have to ask Leslie Lamport or Don Knuth', as it follows from the TeX basics. (For example, \newcommand\foo mirrors \def\foo, and \DeclareDocumentCommand\foo mirrors \cs_new:Npn \foo.)
First, there is an intrinsic consistency for requiring that the 'appearance' at the point of definition is the same as that at point of use.
Secondly, requiring that a token is construction avoids confusion about what can usually appear in a command name. For example, if you did
\declare{foo-bar}...
\foo-bar
the latter would not work (assuming standard LaTeX category codes) as TeX would 'see' the token \foo followed by a hyphen and the letters b, a and r. That looks like a good way to have problems.
Third, the current set up allows 'experts' to skip the { ... } pair
\newcommand\foo{definition}
works in the same way as
\newcommand{\foo}{definition}
something that was important when TeX was 'smaller' (we save two tokens there), but also something that many people find easier to read. (Moreover, as most good editors highlight LaTeX tokens differently from 'running text', using a token-based approach works better with many editors.)
Related to that, you have to remember that the current interface was designed in the 1980s based on a system developed in the late 1970s. The additional work for both \csname expansion and storage of tokens (separate letters rather than a control sequence) was much more important in the past than it is today.
Finally, if you look at the LaTeX3 stuff we want to avoid 'dynamic' definitions as far as possible at the document interface level. One of the lessons of LaTeX2.09/LaTeX2e is that a clearly defined interface is a good thing: encouraging the use of dynamic names does not help there.
Best Answer
\csnameis your friend: