Users care quite a lot when these things break.
>They care about business functionality, which is quite easily expressible in model form.
They care about reliable applications that do the task they want. Users don't have a concept of "business functionality". If a widget they wanted to use is broken, they'll be pissed - they won't tell you that it's ok because the concept of the application was still good.
From your link:
>The main thing that I want to highlight here is how simple the model is. This is pure domain logic, and is probably as close to the essential complexity of the application that we can get
This is exactly the issue.
If I go down my recent list of bugs and categorize them, ~8 out of 10 of them are in areas which the author would have *abstracted away*. The other two probably could have been avoided by having a team member write one test to cover that functionality instead of zero.
What does it mean when you abstract something away from a test? Well, it means the test won't catch a bug in that thing.
If I went down my recent list of bugs and been able to see that 9 out of 10 of them would have been caught via adding property testing/model testing on top of regular testing/typing, etc. I'd have absolutely no second thoughts about implementing it but that simply isn't the case.
I have worked on problems in (not usual) environments where it is the case, and in those rare cases I have advocated for and used property testing but I have more often seen it advocated and used by people who see every bug as a nail and property testing as some kind of super advanced hammer.