Why aren't all math functions wrapped in ensuremath?

It is very easy to do that for \vec:

\let\latexvec\vec
\renewcommand{\vec}[1]{\ensuremath{\latexvec{#1}}}

Now try this

\documentclass{article}
\usepackage{amsmath}

\let\latexvec\vec
\renewcommand{\vec}[1]{\ensuremath{\latexvec{#1}}}

\begin{document}

A sum of vectors $\vec{x}+\vec{y}$

A sum of vectors \vec{x}+\vec{y}

The negative of a vector $-\vec{x}$

The negative of a vector -\vec{x}

\end{document}

See?

These small examples show your idea is doomed to failure: math mode is much more that skewing letters.

Sometimes you have a single vector or math variable in text: using $...$ around it makes your intention clear. But the most usages of math symbols is in complex formulas, where you need $...$ anyhow. Being able to write

the vector \vec{x} is nice

instead of

the vector $\vec{x}$ is nice

doesn't seem so big an advance, particularly because you then are elicited to type

The sum of vectors \vec{x}+\vec{y} is even nicer

(A comment up-front: I do not recommend pursuing the solution shown here. I think it's far, far better to switch in and out of inline math mode explicitly.)

Here's a LuaLaTeX-based solution. It can handle two types of cases:

• math-mode macros that take one argument that must be (or at least should be) encased in curly braces, e.g., \vec{x} and \hat{y}); and

• math-mode macros that do not take an argument, e.g., \alpha and \beta.

I don't think it makes sense to try to extend this setup to macros which take an argument that need not be encased by any kind of delimiter, e.g., \ln2, \ln 2, \sin \theta, or \sin\theta. There are just too many complications to contemplate. I don't think it's reasonable to expect users to write ln{2} or \sin{\theta}; after all, it would take just as many keystrokes to write $\ln2$ and $\sin\theta$ in the first place.

Do note that while this code can handle sentence fragments such as the letters \alpha\ and \beta, it's not meant to handle things like the expression \alpha+\beta is well defined. It also can't handle expressions such as a^2+b^2=c^2 properly; the spacing around the + and = symbols will not be the same as if the math material were were rendered math mode to begin with.

It's the user's job to populate the Lua tables called Table_A and Table_B with suitable math macros. Observe that it's necessary to double up on the backslash characters, i.e., one must provide inputs of the form \\vec and \\alpha. This is because the backslash character serves entirely different purposes in TeX and Lua. In particular, in order to get Lua to search for a single backslash character (\), it's necessary to input the character as \\.

% !TEX TS-program = lualatex

\RequirePackage{filecontents}
%% Store the Lua code in an external file called, say, "mymath.lua".
\begin{filecontents*}{mymath.lua}

-- List of "functions" (macros, really) that should processed in math mode.
-- 'Table_A' is for macros that take one argument enclosed in curly braces.
Table_A = { "\\vec" , 
            "\\abs" ,
            "\\hat" ,
            "\\widehat" ,
            "\\dot" ,
            "\\tilde" ,
            "\\widetilde" ,
            "\\bar" , 
            "\\overline"  } -- as many items as needed    
-- 'Table_B' is for macros that do not take an argument.
Table_B = { "\\alpha" ,
            "\\beta" , 
            "\\omega"  } -- as many items as needed
-- The function 'mymath' does most of the work.
function mymath ( s )
   -- cycle over all items in the 2 Lua tables
   for i,j in ipairs ( Table_A ) do 
      s = s:gsub ( Table_A[i] .. "%s-%b{}" , "\\ensuremath{%0}" )
   end
   for k,l in ipairs ( Table_B ) do 
      s = s:gsub ( Table_B[k] , "\\ensuremath{%0}" )
   end
   return s
end
-- Assign the function 'mymath' to the 'process_input_buffer' callback.
luatexbase.add_to_callback ( "process_input_buffer", mymath , "mymath" )

\end{filecontents*}

\documentclass{article}
\usepackage{mathtools} % loads the 'amsmath' package automatically
\DeclarePairedDelimiter{\abs}{\lvert}{\rvert} % create a new math-mode macro
% Load the Lua code from the external file:
\directlua{ require ("mymath.lua") }

\begin{document}
\vec {x} or   \abs{ -1} or \hat { y } or \widetilde { W}.

The letters \alpha, \beta, etc through \omega.

\bigskip
%% Verifying that the same output results if $ symbols are used:
$\vec {x}$ or   $\abs{ -1}$ or $\hat { y }$ or $\widetilde { W}$.

The letters $\alpha$, $\beta$, etc through $\omega$.
\end{document}

\ensuremath has not been provided to help users to typeset material without explicitly entering math mode (and thus saving 2 key strokes). It is available to ensure that certain things apear in math mode (because technally they have to) even though that is not necessarily a formula as far as the document is concerned.

For example

\ProvideTextCommandDefault{\textdegree}{\ensuremath{{^\circ}}}

defines a text character but it requires to jump into math mode to build it. So if \textdegree is used as part of a formula using explicit $...$ inside the definition would break it.

In hindsight we should perhaps have provided that as @ensuremath to make it clear that this isn't really a document level command. But then, there are cases where users want to define similar things and so it ended up user-level.

But back to semantics. LaTeX is largely about writing a logically structured documents and as part of that it is important to clearly state where the formulas (math elements) are and where the text is. And even a single digit is (normally) a math object, though numbers can be text objects.

Now technically all will be fine if you define \alpha or \vec to jump into math mode if necessary and as you say, you can take care of it looking alright and avoid doing \alpha + \beta wothout surrounding it by $...$. But if you consider the LaTeX source file as something that carries meaning and is potentially processed by something other than a TeX engine then leaving out the markup for math objects is potentially a mistake in the long run.

As a small anecdote (though a slightly different scenario): Don Knuth made a remark somewhere that he got horribly tripped by optimizing his writing and doing things like ...the value can be either 1 or $-1$... in his books. That worked fine until the day he wrote Concrete Mathematics and decided to use Euler math fonts for math and Concrete Roman for text. Of course your case is different, i.e., if you change the definitions all is good as long as you stay within the TeX engine environment. But that may change one day and then it is just missing markup that changes the semantics.