in %dx, %al assembles to the same 0xEC byte of machine code, which objdump -d disassembles to in (%dx),%al as you've found.
llvm-objdump -d does use the syntax you expected: inb %dx, %al ; inb $128, %al
AT&T syntax's use of (%dx) for the IO port number in in / out is misleading since it's not a normal addressing mode; DX being the only option. Presumably the designers of AT&T syntax wanted to represent the fact that you're reading or writing I/O address space. But they did a bad job because it's inconsistent with their use of in $0x80, %al for immediate port numbers (as opposed to 0x80 for the port number using the same syntax as an absolute memory address). GAS and LLVM don't even accept in 0x80, %al, so no, not "Just like in 0x000,al".
The in / out instructions access IO space, not memory address space.
The "addresses" in IO space are called port numbers.
IO space is still a thing in modern PCI-express, but most modern devices only have MMIO registers in device memory regions, not IO ports, because IO ports are slower to access.
objdump -drwC -Mintel disassembles to the same syntax Intel uses in their manual entry for the only form of in that has a port in DX and byte operand-size. Note the lack of [dx] brackets.
0: ec in al,dx
1: e4 80 in al,0x80
(%dx) is not one of the valid 16-bit addressing modes, so that specific addressing mode is never valid for any other instruction. But yes, (%reg) such as (%edx) or (%bx) is AT&T addressing-mode syntax for memory operands in instructions which allow a normal reg/mem operand such as mov or add.
See also Why there is no parentheses wrapping around AL register?