The hieroglyphics are a burden: you have to learn to type then, you need a good font to distinguish them, you need larger font sizes to distinguish them, you often can't share your code casually and need to take screenshots of it, and the more convenient input methods have you often using one program to get a glyph to then copy and paste into another program. J has a very direct translation of APL's primitives into ASCII which is functional, and K reinvents APL's primitives for a much nicer ASCII rendering. Visually, they're all equally an affront to the non-array programmer.
It's a "write-only language" that's a barrier to contributors, that management will regard as a job-security choice, and that has the infamous Forth problem of: if a manager points at a random line of your code, you probably can't immediately explain it the way you could explain a single line of another programming language's code.
APL has all these ancient design decisions that have been found wanting with time but which can't be fixed now.
It has a context-dependent grammar, meaning you can't reliably read a string of APL without knowing how the variables are bound.
Lexical variables? Closures? Hashmaps? Trees? 404 Not Found
Implementation options: Dyalog (expensive, proprietary), GNU APL (archaic, less actively maintained), various hobbyist incompatible dialects, or abandoned.
BQN
If you're going to take the hit and use hieroglyphics, why not at least pick the standard language with the standard glyphs? APL has books, history, famous code examples, a big company. You really want to throw all of that away and still need special characters?
It only has a single numeric type.
It has fewer libraries and fewer resources.
The array model supports scalars as distinct from unit arrays, which leads to the language feeling less rank-polymorphic, with list-only features like Fold that exist just to return a scalar.
@ as the don't-care/nullary argument is weird, OK?
Recursion is favored for control flow, but implementations lack tail-call optimization and have shallow stacks.
It has nothing for concurrent or parallel programming.
J
J's ASCII notation is exceptionally off-putting with its unbalanced braces and digraphs.
J feels like a compromise language that carries the APL tradition forward while hewing closely to it, only fixing some small inconveniences, but lacking a radical reconsideration of the language. The tradition is also an older one, with J only belatedly picking up dfuns.
Hooks are confusing, especially as part of a longer train.
You have to memorize magic numbers for !: (foreign)
You have to memorize magic numbers for o. (circle function). How is that better than cos(), tan() names?
You have to memorize magic numbers for : (Def). Even though names exist, J programmers don't use them.
You have to memorize magic numbers for ;. (Cut), and the elaborate usage of ;: (Sequential Machine), and more.
J has a very large number of primitives and also a very large stdlib - it's a lot to learn. In a way some primitives can even prevent exploration of other primitives: I used J for years without thinking of mutating with &. (Under), only considering that when BQN just didn't have an Amend.
J is sometimes strangely limited: a script can't take interactive input from stdin, there are no mutable hashmaps.
Boxes are the computing equivalent of phlogiston or aether. An unnecessary complication to the array model.
The empty string as the don't-care/nullary argument is weird, OK?
J doesn't have good in-browser options, and jhs is a bit too scary to use for public-facing applications.
K
K is not even a language. There's the K underlying Kx Systems' kdb+ which is a language. There's what Arthur Whitney's working on lately. There's a long trail of imitators, all unalike and usually discarding surprisingly significant portions of atw's designs.
kdb+ and Shakti are proprietary and extremely expensive. The imitators are all hacker software with a deliberate disdain for meeting commonly-expected levels of usability or documentation.
K's array model is simplified to the point of just being Lisp.
K sheds so much of the APL tradition that you can't take APL code or techniques into K without heavy translation, or vice-versa.
K tends to have an enormous amount of overloading. A dyadic $ in Goal can be one of 11 different primitives.
Lil
This is a scripting language for Decker and not a general-purpose programming language.
It has an unserious APIs, like the dangerous shell[] that takes a single string.
Like K it's a reinvention that's been optimized for the author's purposes, which means greater friction as your purposes differ from the author's - even non-ASCII characters are too far for terminal lil, and even performance is kept consistent across devices with deliberate sleeps (in Decker).
Performance is poor in general, even for array-friendly code. About half as fast as Python?
One of its rationales is a very small implementation (smaller than Lua's), but it's still not as small as bqn.js
Lil has no runtime errors at all, making it potentially very maintainer-hostile, with wron_name[] and much else silently returning zero.
Lil is frequently much more verbose than similar languages, using a SQL-like language to replicate single-character primitives in BQN, K, and J.
Is this even an array language? Isn't it just a macro processor, like m4? If having some array-oriented functions in a library makes an array language, maybe I should add some reservations about NumPy.