It's difficult to fund enough skilled programmers to work on stuff like this full time, and productionize the results in a coherent product. A good example is a sibling comment that says "it would mostly be easy except for the GUI" and that's assuming "no allocations." The things customers pay you for are often the hard parts like that stuff, not the theoretical parts you can enjoy from a PDF. It sucks, but it's true: you're selling a production quality tool to picky-ass programmers. I say this as someone who has a copy of that book you mentioned and has implemented type systems, domain specific analyzers, used datalog (Souffle) a lot, etc.
You also need to know your competition, and the story is even worse there. As I've watched security engineering advance over the years -- and I know you aren't specifically talking about security, but go with me here -- one of the only methods that has actually gone from "nascent infosec curiosity" into full-blown large scale usage by major and minor players has been fuzzing, which most people know as just "throw random shit at it until it breaks". That's because it's often easy to integrate, has few visible thorns in practice, has a surprisingly high signal-to-noise ratio, and can be performed even with duct tape and glue on an existing codebase. It can be done in any language. It often delivers positive results immediately in the short term and continuously over time. That's actually what your userbase considers "easy to implement", not "learn datalog and abstract algebra to understand and integrate domain specific static analyzers into your build system." Is it powerful? Yes, and I like solutions like CodeQL or MIRAI (for Rust). Do they have long term benefits? I think so. Is it easy or at least "not that hard"? I'm not immediately convinced.