I must be missing the explanation here?
The explanation tells you where the problem is, but not what it is.
[font="Courier New"]select '19.4615381' * -1.0;[/font] uses constant expressions, for which SQL Server has to infer the data type. For '19.4615381', the infered data type is varchar(10); for -1.0 it is numeric(2,1).
To determine the data type of the result, two BOL pages are important:
* Data Type Precedence (https://msdn.microsoft.com/en-us/library/ms190309.aspx) - specifies which data type gets converted when incompatible data types collide.
* Precision, Scale and Length (https://msdn.microsoft.com/en-us/library/ms190476.aspx) - specifies resulting data type based on operation and input data types
In this case, we combine varchar(10) with decimal(2,1), so the rules of data type precedence state that the varchar(10) has to be converted to decimal(2,1). But that data type only allows values in the range between -9.9 to 9.9, so the value 19.4615381 causes an error.
It gets even more interesting if we make a small change: [font="Courier New"]select '19.4615381' * -10.0;[/font] will not throw a run-time error; it returns -195.00. Here the inferred data type for -10.0 is numeric(3,1), which allows -99.9 to 99.9; 19.4615381 falls in that range but loses precision, so it is rounded and converted to 19.5. This is then multiplied by -10.0; the rules in the second link state that in this case the result of the multiplication is numeric(7,2) so no further loss of precision will occur.
A very simple and quick way to find out what data types SQL Server infers from constants or uses for the result of any expression is to drop the values in a table and then run sp_help, as shown here:
SELECT '19.4615381' AS a,
-1.0 AS b,
'19.4615381' * -1.0 AS c
EXEC sp_help dbo.x;
DROP TABLE dbo.x;