For me, the only way to meaningfully assign meaning to a program being "beautiful" or "elegant", is to interpret it as the program possessing a significant part

For me, the only way to meaningfully assign meaning to a program being "beautiful" or "elegant", is to interpret it as the program possessing a significant part of all the possible pragmatic advantages a computer program can possess, so on the highest level: being easy to understand, extend and debug. Those easily translate to more concrete properties: strong correspondence between the abstract concepts of the program and the domain it represents, following established coding standards, making functions/methods data-driven where possible, signalizing errors in a meaningful way an so on. There are lots of programs with more then 200 lines that meet a very high standard of elegance understood in this way (v8, sqlite). If your program isn't elegant in this way, there is a real cost for both the users and the business owners, this isn't just some abstract game. I guess you wouldn't like to drive a car where the cables and pipes form a completely unreasonable mess, just because it happens to work at this particular moment of time. If your program is a mess, it will end up having more bugs, features will take longer to develop, it will most probably work slower and so on and so forth. The article implicitly assumes that pure functional programming contributes positively to elegance, and since it doesn't define "elegance", it's hard to argue with it. I don't think however there is a strong consensus in the programming community that pure functional programming contributes positively to "elegance" understood as defined above, and this is to me the fundamental flaw of this article.