In my experience arguing with people about these kinds of bugs--which I have done a lot of, as people would write apps that are buggy and then blame me for their app being hacked, as, clearly, if jailbroken phones didn't exist or were more illegal or whatever, they would have been safe--a lot of the time people are under the impression that their code on the client is secure. They will believe:

1) that it is effectively impossible to reverse engineer binary code and understand it (particularly so if it is obfuscated in any way at all, as the security claims made by the people who develop such tools are often absurd).

2) that it is additionally possible to prevent the hacker from getting access to even their binary, as it is encrypted by the app store and might require jailbreaking the device; either way, it is akin to piracy and thereby illegal.

3) that it is possible to add further mitigations to prevent people from analyzing your app, such as certificate pinning for all of your network requests, or trying to verify the device is "authentic" and not running a jailbroken OS.

Now, "obviously", all these beliefs are all false; but the problem is that, in some sense, they also are not entirely wrong, and so they stick: I am extremely competent at reverse engineering, but I am going to groan given the task of reverse engineering an iPhone app if I find myself forced by certificate pinning to work around some obfuscated network checks after stealing a copy of the app using a jailbroken phone... like, these mitigations actually do make it a lot more annoying for me to do any of this work, and I certainly am not going to that much effort in a casual drive-by fashion.

Meanwhile, client-side security is also a thing the industry relies on in other ways: developers want to limit denial of service attacks or limit piracy of their product or limit external access to private user data stored on the device, and these techniques that "don't work" can certainly raise the bar for an attacker, and so aren't considered dumb in the general case.

I think the real core education is that people don't understand how to determine what kind of credential should be required to access what kind of information, and that different pieces of interoperating software might all possess different credentials, and the limits on those credentials need to be honored.

This also comes up with things like with tokens for various services: people will sign up for a service, and then store the with token in the app so they can make API calls from the client... but now, I have their auth token, right? They don't get that, and part of the reason is that a lot of services kind of encourage that model. And like, with your OpenAI key, at least the damage is probably "just" monetary; but, if it is your AWS key, suddenly it is super serious.

So, yeah: I think developers will, in fact, say stuff like client-side filtering "isn't that bad", or that "it might be justifiable under some circumstances"; and they might even be sort of almost right at times for certain kinds of checks (not with other user's data, of course ;P) under certain kinds of tradeoffs... but then misapply the boundary in a way that is flat-out incorrect.

Now, is this article the article that would explain this or convince the developer that these cases are wrong? I don't know... it isn't even clear to me that that's their audience, as opposed to being more of a portfolio piece that the author does understand this issue and thereby is competent at one or both of security engineering or website development (and, FWIW, I think it is sufficiently successful at that).