Replay attacks against OpenVPN indeed require the attacker to be in a man-in-the-middle position, because they have to capture UDP datagrams from a legitimate OpenVPN client and then replay those datagrams.
The consequence of a replay attack is that an attacker can duplicate the IP packets which are encapsulated in the OpenVPN UDP datagrams. This may be used to, for example, perform a SYN flood attack against a TCP connection within the VPN, as pointed out in the OpenVPN manual for version 2.4. SYN floods are a type of denial-of-service attack which can render a network host unable to receive traffic from legitimate hosts.
Changing the replay window doesn't affect the risk of a replay attack, but a short window can lead to packet loss and more warnings about potential replay attacks. In a network, it's possible that the UDP datagrams sent by an OpenVPN client arrive out of order. To account for this, OpenVPN uses a sliding-window algorithm similar to the one from IPSec: Each OpenVPN packet gets a packet ID. If a packet is out of order but still within the window, then it will be accepted – unless it's a duplicate, in which case a replay warning is triggered. If the packet number is below the lower bound of the window, then it will be rejected. In the latter case, it's unknown if the packet is a duplicate of an earlier packet, so OpenVPN will warn about a potential replay attack. There's no actual risk, because the packet is dropped anyway, but you'll see this warning in the log.
