If you subscribe to a policy of "Clean Code", then you probably need to ask yourself if it is good practice to add comments at all. If the code can only be clarified with a comment, then sure, add one, otherwise you should be able to easily understand what your code does simply by reading it (provided you are using sensible names for your variables, methods, Etc.).
Regardless of your personal view about whether commenting is good practice or not, a comment should contain information that is of direct value to the code that the comment is referring to. In this case, the question is whether adding an issue number adds value to the code. The problem I see with adding the issue number is that you can have a section of code that might be modified heavily in order to satisfy several issues, and after a while, it could be impossible to correctly identify which changes related to a specific issue. Subsequent issues for example may require code relating to prior issues to be heavily refactored. This is perhaps an extreme example, however it does show how the issue numbers in comments in code can turn out to be pretty useless.
If you could guarantee that the situation I have just described would never happen, I'd still argue that the issue number itself is still pretty useless without a description of what the issue is about, and yet, all of this information really belongs in your issue tracking system and should need to be duplicated. A better place to note the issue number would be in your version control system as a commit comment. The advantage is that you can compare versions and see the code changes relating to a specific issue, while the issue number itself provides you with the identifier needed if you want to review the reason for the change in the code.
With all of this in mind, I'd suggest that it is not really good practice as such adding issue numbers into comments within your code.