No need for speculation. Go ahead and say it: 124 points on HN's front page objectively proves it was successful in being interesting [to more than a handful of people]. Exploration into minimalist languages sometimes leads to interesting, practical constructions as well like seen with LISP's, Forth, and Lambda Calculus. Far as time wasters go, such experimentation has a higher chance of going somewhere than some others.
It's great as a first attempt to delve into the strengths and shortcomings; you can't learn what won't work until you try. The author should explain the motivations after this design, and could get hints from other similar languages to improve the language.
IMHO the notation has several shortcomings that would make it very hard to use in practice, and not the best strategy for working with functions.
Maybe it's my fault for not seeing the purpose of this approach; but in my experience, free-form graph-based language work best when they emphasize working on collections and data streams, rather than on scalar function parameters. For the kind of example problems expressed in the article, a tree-based notation would work better.
Timwi does have some other useful projects though (take a look at his github), all of which are basically centered around parsing. (an IL debugger, a C# parser, generic regular expressions...)