Yes, it is beneficial.
When you do not salt (or pepper) the password, the password isn't very strong and an attacker obtains the hash, it can be cracked by just looking up the hash in a rainbow table (a precomputed list of the hashes of the most common passwords which can be found online). But when you add some additional data to the password, a precomputed rainbow table is useless and an attacker has to compute the hash of every common password themself, which takes considerable processing time, especially when you use a slow hash function (which is recommended).
When your salt is always the same (which means it is a "pepper") and an attacker obtains that pepper, they can precompute a rainbow table for that pepper which can be used to crack any future password hashed with the same pepper. When your application is widely-deployed and each deployment uses the same pepper, it would be feasible for an attacker to precalculate such a table in order to increase efficiency when targeting multiple deployments. When your application is only a single instance, such a rainbow table could still be useful. A possible attack scenario would be when there would be some vulnerability which leaks the hash and you don't know about that vulnerability. Without a rainbow table, it might take a long time for an attacker to crack the new password after each password change, which would buy you some time to find and fix the problem. With a rainbow table, it would only take seconds to crack any new password you set.