Array languages (Jelly is one of them!) work at a high level of abstraction, since programming consists of applying operations to entire immutable arrays. List comprehensions are probably the closest the mainstream gets to this style.
It's not as abstract as possible or anything. Most directly, there are abstractions like algebraic datatypes or macros that APL doesn't have at all. And there's a sense in which APL is very concrete: it tends to use first-order functions instead of higher-order ones like Replicate[0] instead of filter. For me the fact that an array oriented program tends to handle just a few arrays at a time makes it easier to understand what's going on. I think there are also ways in which APL programming is low-level. Going back to Jelly, it's actually a stack machine, same as Java object code, or Forth. Modern APL has tacit programming[1], which has a similar mix of mathematical purity and machine-like shuffling. I think the way APL handles array axes is similar. They are numbered, so to work with them you have to keep track of the ordering. Something like einsum that names them would be higher-level.
One of the most memorable and interesting things I've ever seen on HN was an AMA from the creator of the Co-dfns parallel APL compiler. Here is co-dfns [0] and the AMA by the creator [1]. The video may give you some insight and at the very least may be extremely interesting to hear the APL code explained (jump to around 13:30 for the beginning of the explanation behind the structure + what the compiler is doing). He explains it very well - it's quite easy to follow along.
Array languages are arguably more abstract. Rank polymorphism allows semantically the same program to work over various array ranks, where the execution meaning is derived from the context which is the shape of the argument. You can find these in some natural languages, which can have single phrases which you cannot know what it means unless you have the wider context.
Next, array languages abstract away the execution strategy of loops. You as a programmer do not pick whether you use an accumulator or divide-and-conquer in your loops. Some good parallel libraries like Rust's rayon arguably have this feature in the imperative model, but it's not exactly a language feature of Rust.
W.r.t. machine languages, array programs do not have typing information which I think is the case for all modern intermediate representations.
As the author of https://staxlang.xyz/ for me, it's pretty far away from machine code. Golfing languages tend to be pretty impractical, as they optimize for program size above all else. That includes readability, performance, and consistency.
Machine code can be practical. To me, code golf is just pure programming, for no practical purpose. It's not for everyone, or even most people. It's more like art than practical programming. Except it can be competitive? Not sure really.
It can also be fun just to build something, without the risk that you might accidentally get a significant number of users.
As a commenter touched on above, these languages are purely for "golfing". Programming golf is when you challenge yourself to solve a problem in the fewest characters possible. Golfing languages therefore, are languages where the aim is to jam as much common functionality into single characters as possible. There is no real practical use for them.
Closer to a very high level of abstraction in a quite restricted language. Array-based languages have lots of advantages for certain problems for those who have put in the requisite time (certainly not me!). They're one of the languages that'll expand the way you think of programming.
I came to APL looking for a compact code representation for a problem in hand (had to add transformations to data which was passed around over slow links). Not only APL is compact, it's different in an interesting way, which deserves learning by itself.
Or is this the exact opposite, operating at the highest level of abstraction?