Should a table have a foreign key to another table if it already has a foreign key to another table that has that foreign key? That was a hard title to digest even for me so I'll break it down.

I'm very new to SQL, and I just designed my first database. I also am not very good at JOINS which might be the answer to my problem. But to get back on track I currently have three tables of interest:

comments

   id    |      author       |     category    | date_submitted 
---------+-------------------+-----------------+----------------


replies

   id    | date_submitted | comment_id 
---------+----------------+------------


images

           image_url            | reply_id |                    original_id                    
--------------------------------+----------+---------------------------------------------------




So given this, the question came to mind when I was trying get a table with the columns comments.id and images.original_id, an operation that I would like to do often.

Currently to do this I can't directly JOIN comments and images because they have nothing in common, meaning that the middleman has to be the replies table. So I have to JOIN replies and images and then JOIN that with comments.

So my question is this. Would it be okay to add a foreign key column referencing comments to the images table so that I can directly JOIN the two tables instead of going images -> replies -> comments, or would it be bad practice to add a foreign key that I already have to access to through the replies table?
It is not a good practice for many reasons. The most important one, design principles, you should never mix entities just because it is easier for the programmer/dba to do queries. Entities should be as clear as they can and must exclude any other information not related to them.

For your scenario, to make it easier for future querying, you can create a view that does the join and instead query this view.

Regarding any benefit that could be possible while cutting a join, there are other costs maintaining the foreign keys, so there is not really a huge advantage either.

If you are in SQL Server, you can create an index for the view, which materializes the view (creates an underlying table with the data) and you will have performance as querying a single table.