Depends on your use-case and the tradeoffs you're willing to make. SHA1 is slower than the the top finishers of the SMHasher suite [1], even if it's hardware-accelerated. Meanwhile, SHA256 and later are currently considered to be suitable for cryptographic use, so if you're not sensitive to the size of the hash output, you may get additional nice properties that you didn't intentionally design for. But they're even slower.
If you're shipping a black-box component that needs to use hashing internally, and the hash outputs don't leak out of the black-box, consider switching to a faster non-cryptographic hash to gain performance. Consider the implications of switching -- dependencies, trust, performance profile, hash output size, documentation, customer expectation -- and you will have to discard or otherwise invalidate the meaning behind of your past hash outputs.
If you're occasionally applying a hash function and obtain a digest that gets put into long-lived files or records, e.g. you're checksumming your own files for sanity and then verify them later against these records, then you may value availability and stability more than you value performance. If so, don't switch.
If you are fine with the current performance profile, the cost and complexity of switching (or any nontrivial change) may outweigh the benefits of leaving everything as-is.
I am always interested when these get attention, but I don't know enough about the implications to switch over from just using SHA.