I have experience working with large codebases in K. In practice, most of those codebases don't look dramatically different from any other garden-variety dynamic language. The high-level architectures are similar, and intrinsically-serial business logic still tends to have a lot of named function calls and conditionals. The algorithmic parts, where real work is happening, shrink down to little clusters of operators here and there. Prototypes of new systems and services can be written in a terse, brick-of-code style like some of the K you may find online, but as they get integrated into larger systems they tend to grow comments, descriptive identifier names, and shorter, more diff-friendly lines.
I've never found it hard to come back to reading K after long absences, in no small part because the set of primitives in K is a small fraction of the set in J (or uiua) and the notation, while terse, is more suggestive and legible to me than J's emphasis on digraphs and forks, or the "unicode-soup" of mismatched characters that some modern APL descendants reach for. K is an equally excellent notation for experimenting in a REPL or discussing ideas on a whiteboard.