> I mean, does this add any security?

No, or he would have mentioned it.

It's clearer (especially as the number of parameters increase) and easier to change (in order to e.g. add a new parameter)

It's not more clear when you're trying to examine the codebase as a whole.

Of course it is. Names are clarity. Position-based binding sucks. I wrote a quick extension to java.sql.PreparedStatement at work one evening this week to enable named parameters specifically because of this.

Named parameters also make it easier to re-use queries (have a queries file or something) because you're much less apt to immediately break something by changing a query if everything is explicitly bound via names. And you can make the statements as a whole more terse if you'd like; I intentionally wrote it verbosely.

In the first example above, you have one place where you have position based binding that you could break while reusing or refactoring.

In your example, you have one place where you have position based binding that you could break while reusing or refactoring.

In my experience, people are vastly less likely to rename a variable than move it to a different place in a query.

There's also the proclivity for people to want to reuse the same value in multiple places in a query. Name-based binding makes that a lot more readable and straightforward.