I'm the author. It's a fair point - I wasn't sure how concrete I wanted to get about my specific experiences. Or maybe I was concerned about people being able to trace my actual job history. Then again - it's all on LinkedIn anyhow so I guess those were invalid fears.
The author does mention Datomic at the bottom of the post, along with CQRS (by which he most likely means storing events) as other options. HE then mentions that he's stuck using an RDBMS so Datomic is not an option.
The one thing I would add is that using an RDBMS does not preclude you from storing events along with your relational data. So you have a representation of current state, but also all of the events that took place to get you to that stage. And that will give you the same type of history.
It's definitely much easier to convince people when you're talking dollars rather than "beauty" or "maintainability" which are much more abstract concepts. This pushes that to the forefront.
I wonder if anyone has experience with trying to use this language that they can share. I'm curious because it seems like a great idea. But I wonder if it would solve the "just ship it!" mentality. I still feel like there may be a missing component which is that what might be fast to build now will slow down the overall development effort later on. I think that time gap is one of the big things that stakeholders fail to think about. They're thinking "what can we get out the door now?" and not further down to what impact that will have on getting other things out the door a few months from now.
It sounds like you already know the answer, considering you said you'd ignore anyone who says you should give up. :)
Of course you should forge ahead with it. Your best bet is to probably to go with your gut. Look for a programmer to partner with and in the meantime, maybe grab a few books on programming so you could help (even if its with menial stuff).