I've been arguing for some time against embedding server-side tags in JavaScript code, but was put on the spot today by a developer who seemed unconvinced

The code in question was a legacy ASP application, although this is largely unimportant as it could equally apply to ASP.NET or PHP (for example).

The example in question revolved around the use of a constant that they had defined in ServerSide code.

'VB
Const MY_CONST: MY_CONST = 1
If sMyVbVar = MY_CONST Then
    'Do Something
End If

//JavaScript
if (sMyJsVar === "<%= MY_CONST%>"){
    //DoSomething
}

My standard arguments against this are:

1. Script injection: The server-side tag could include code that can break the JavaScript code
2. Unit testing. Harder to isolate units of code for testing
3. Code Separation : We should keep web page technologies apart as much as possible.

The reason for doing this was so that the developer did not have to define the constant in two places. They reasoned that as it was a value that they controlled, that it wasn't subject to script injection. This reduced my justification for (1) to "We're trying to keep the standards simple, and defining exception cases would confuse people"

The unit testing and code separation arguments did not hold water either, as the page itself was a horrible amalgam of HTML, JavaScript, ASP.NET, CSS, XML....you name it, it was there. No code that was every going to be included in this page could possibly be unit tested.

So I found myself feeling like a bit of a pedant insisting that the code was changed, given the circumstances.

Are there any further arguments that might support my reasoning, or am I, in fact being a bit pedantic in this insistence?