I will let @Erland Sommarskog answer to this question with authority but just quoting few lines from the same blog
Before I go into the real solutions, let me first point out that adding SET ARITHABORT ON to your procedure is not a solution. It will seem to work when you try it. But that is only because you recreated the procedure which forced a new compilation and then the next invocation sniffed the current set of parameters. SET ARITHABORT ON is only a placebo, and not even a good one. The problem will most likely come back. It will not even help you avoid the confusion with different performance in the application and SSMS, because the overall cache entry will still have ARITHABORT OFF as its plan attribute.
So, don't put SET ARITHABORT ON in your stored procedures. Overall, I strongly discourage from you using any of the SET commands that are cache keys in your code.
If you ask me personally this is a "good workaround" and works for most cases. If you have SQL Server 2016 or above using Query store you can force query to use plan which runs fast and that would not need ARITHABORT ON. Before that using plan guides is the solution to get over such things.
PS: For ordinary Joe this has mostly been the solution.