Pretty much all of them. In addition to story points and lines of code, developers have been measured based on tickets closed, tests written, code reviews sent

Pretty much all of them. In addition to story points and lines of code, developers have been measured based on tickets closed, tests written, code reviews sent and received, revisions per code review, and so on. None of these should be used as a naïve input to performance evaluation for software developers. However, that isn't to say that they aren't useful for evaluating performance. One way they can be useful is to compare peers, look for outliers, and try to understand what is really going on. Often times these are just going to be noise that are specific to the project or system they work on and not the quality of work. But sometimes these quantitative metrics and help identify interesting patterns. For example, maybe a dev is an outlier in number of code review comments because they are a time-wasting nitpicker, or maybe because they are using code reviews as a tool to mentor junior engineers. I think when used this way, these quantitative metrics can be a way to highlight areas of particular strength or weakness that the manager might not realize if they are just going on what they see incidentally. You have to trust the manager, or whoever is doing the performance evaluation, to use these tools for good and not evil.