Lisp lists are not Java List<T> instances. There are some automatic conversions (e.g., from Lisp numbers to Java numbers) but not for lists or hash tables. You could invoke Arrays.asList(...) in Lisp as well, I don't remember the exact syntax to do that as I haven't been using ABCL for years.
Granted, it wouldn't be much work to either have Cons implement List<LispObject> or provide a cons-backed List<T extends LispObject> implementation. However, the devil is in the details – how do you convert those LispObject's to the appropriate Java type? Is it Integer, Long, Double, ...? Generics are erased at runtime, ABCL couldn't possibly know, so we'd need another primitive, e.g., (jcoerce-collection collection &key element-type (collection-type "java.util.ArrayList")). But then one would have to know about it in order to use it.
ABCL could also do type inference and deduce the type of the elements of the list from how they're used in the code, e.g., from the call to parallelize. But 1) it's a lot of work to implement 2) it doesn't solve all problems, e.g., I guess parallelize is itself generic like <T> List<T> parallelize(List<T> data) or something like that, in that case, you as a user would still have to spell a type name.
BTW – it gives me warm fuzzy feelings to read that you see extensible sequences as a feature worth mentioning. I did the porting from SBCL back then but it didn't look like it was used much. FWIW, back then I also integrated CLOS dispatch with the Java class hierarchy – it may have bit rotted, but you could write, e.g., (defmethod foo ((bar (jclass "java.lang.List"))) ...) and it would do the "right thing" wrt Java inheritance. But hey, maybe it's undocumented as well.