Providing extra foreign keys
In case if I want to figure out user's department while selecting data from tasks, how do I build the query for it?


You'd first join user and then department.

SELECT *
       FROM task
            INNER JOIN user
                       ON user.id = task_user.id
            INNER JOIN department
                       ON department.id = user.department_id;


Such "chains" of joins are no problem for a DBMS in general, it's built to do that (but you should consider proper indexing to support it (but that's also true for queries not using joins)). The "shortcuts" you have in mind on the other hand bring a certain level of denormalization and with that a handful of problems.

Whether to include department_id in tasks depends on what you're trying to model.

If a task can be assigned to a whole department without a specific user from that department, you'll need it. Add a check constraint enforcing that one of both is null, to be able to distinguish between task assigned to only a user and those only assigned to a department.

If only users can have tasks assigned, you won't need it. You can query the department as shown above. Further more in that case it's dangerous to include it or at least it makes things more complicated. You have to check then, that the integrity isn't violated. Say if a user assigned to a task is in department A but the department assigned to the task is B. That obviously doesn't match. Unless users can be in several departments an a task should be assigned to a user in the role as a member of a specific department. That's one of the problems of denormalization I mentioned above.

(You see, there are many ifs here, you need to think through. Maybe even more than I just came up with!)

If you don't need the department_id because of the logic, I'd recommend not to use it in task. It most likely brings more problems and doesn't even solve another as joining usually is no problem.