Although Julia goes further in other directions, just changing the surface syntax of s-expressions, like this proposal, doesn't really interfere with this feature. With alternate syntax, you can still write macros and stick to the code-as-data idea in pretty much the same way. In Lisps with a programmable reader (like Common Lisp and some Schemes), you can set up the reader to recognize something like foo[bar,baz] as an sexp, and once read, it'll be represented internally exactly as if (foo bar baz) had been read with the default reader. Then any macros and even code-walking code continue to work the same as before.
And while programmable reader macros allow Lisp to have any syntax you want, they go even further in producing heterogeneous environments in which not even the parsing rules are shared. But you can't just only know the algol/infix way of programming in Lisp since you'll have to see other people code and documentation, and when you use these alternate parsers/extensions other people have to understand the quirks of your unique parser/extension before understanding your code. Everyone using the exact same language is definitely a feature, and those languages (and clojure who dropped programmable reader macros and asks people to use macros more judiciously) have a point in their belief.
But as a curiosity, Julia also has it's own version of reader macros [1], which can be used to give it s-expression syntax [2].
[1] https://docs.julialang.org/en/v1/manual/metaprogramming/#Non...
Being not as powerful (able to create any valid syntax due to more complex and rigid parsing rules) and trivial to manipulate code as data as s-expression is considered a feature, as it helps preventing the proliferation of language extensions while still allowing them when their benefits outweighs the costs. Even the main elixir metaprogramming book starts with saying: "the first rule of macros: don't use macros", and in Julia you have to attach a @ to call a macro to make it clear that the normal rules of the language do not apply ahead. Those languages also focus in providing everything the user needs without the use of macros, which are for more advanced purposes.
While people who use Lisp eventually see the advantages of s-expressions (or at least of writing more idiomatic code in those languages), being attractive to new users coming from the more popular languages is very important (and like clojure interoperate with java, it might be even easier to make a lisp that has perfect interoperability with Elixir for example, so both groups can coexist).