First, there is a source of confusion between the table you're showing and the diagram. The table and diagram both use the term "ALUOp" but for the diagram this is the term for the output of the "Control" going into the "ALU control", whereas for the table this is the term for the output of the "ALU control" going into the ALU!
Can't ALUcontrol tell ALU what operations to do by just receiving 5-0th bits? If so, all the ALUOp signal can be all same for the R type.
Not directly, it doesn't appear so. I don't see a simple bit pattern in the bit 5-0 that would result in the proper "ALUOp" shown in the table, so a lookup is necessary, which is what "ALU control" is doing when the ALUOp coming from Control is for 000000 (R-type).
I don't know why ALUcontrol needs to receive data from both instruction and Control when ALUOp for R type looks useless.
This is because "ALU control" is also used by I-type instructions — lw & sw, addi/u, which use the add function of the ALU in computing an effective address, as well as slti, andi, ori, xori, which also require the ALU. Note that the ALUOp for lw & sw is 010, the same as add (as they use the ALU to compute the effective address). Further note that the ALUOp for sub and beq are also 110, which makes sense because a beq is comparing the two (albeit for equality, so xor might also have been used).
We don't see the other I-type instructions in the table, but you can imagine the slti/u also use ALUOp 110 for subtraction and addi/u also use 010 for addition, and that, andi, ori, xori, use the same codes as and, or, xor.
The J-type instructions have their own dedicated adders so, no need for ALUOp.