Sure, a fancy calculator that supports rather efficient execution on ridiculously large machine farms. What some people might call the implementation language for a database engine.
Real time processes are indeed critical in some contexts. And, arguably, we should be putting more effort into some of those contexts.
For the APL family, that's often a call for code which works with external interfaces. In many potential APL environments a handful of well designed custom primitives would get you where you need to go.
But no programming language is adequate for all roles, and that includes APL. (It can still be useful for modeling / prototyping for real time work, but that's not always necessary.)
J has primitives (like I. and i. and e. and the primitives which set up for their use) which serve some of those roles.
But, yes, approaches which use some kind of array representation are highly favored by the language (and by other languages, to varying degrees, once you understand the patterns and issues).