@Hristo Ivanov - It is not a bad practice. Here is why.
1) ServiceNow engineers have themselves created many such Client Scripts. See example snip below.
Also, in some cases they have hard-coded sysID's of the records itself. See example snip below.
Reason - In some cases the solution can have multiple approaches. In the examples above you can see, ServiceNow engineers have created such client scripts because they couldn't achieve few scenarios. Hence, they had to take that route.
As a matter of fact, the solution you have provided using "Add a state model and transitions" uses the same onLoad client script to achieve it behind the form. If you open the onLoad client script for that functionality you will see that. See snip below of that onLoad client script which is actually helping you achieve it from "Add a state model and transitions".
For which I have created the onLoad client script directly. Whether you take "Add a state model and transitions" route or directly create onLoad client script it is doing the same thing behind the form.
It is just that they have made it low code for people who do not wish to write client script and achieve it differently based on scenario.
2) Performance - It won't impact performance. See browser response time. It is 0 ms. There are other factors that involve performance. Such as, creating scripts without proper conditions, while form is loading. I could add the "isLoading" check to see if the form is loading, and if it is then I can return the statement from there. Second, when you have created multiple client script's or BR's around the same field, other fields of the same table where it shouldn't load at all or some complex calculation or may be some additional scripting that is validating data on the backend.
If you put proper conditions before the scripts load then it won't impact the performance.
Hope this helps!
Regards,
Vikas K
