Neither solution is different with regard to SNI. The client will send it, in the clear, whether HAProxy is merely "sniffing" the SNI and forwarding the connection to a backend based on its contents, or HAProxy is terminating TLS.
This is because, in TLS, the client "talks first" -- when the first device on the server side accepts the client's TCP connection (always HAProxy, regardless of configuration) the client initates the TLS handshake with its "client hello" message, including SNI.
If HAProxy is sniffing the SNI, it simply buffers what the client has sent, opens a second TCP connection to the backend (the first connection is to the browser), writed whatever the client has written, and then tying the payloads of the two streams together, tying up a connection to the server for as long as the client is connected, and placing the CPU burden of TLS on the backend server. In this configuration, HAProxy can't make any sophisticated routing decisions (such as by path patterns or cookies) because those pass through the proxy, encrypted.
If HAProxy is actually terminating TLS, then it has access to the unencrypted payload, can make routing decisions based on attributes of the request, and -- importantly -- can optimize the use of server resources by reusing server connections for different clients, and maintaining a typically much lower number of server connections than the number of connected clients, since clients will tend to sit on idle, open connections. HAProxy's event-driven model allows it to manage these idle connections at a much lower cost in resources than some web servers can. If you need the traffic from HAProxy to the backends to be encrypted in this configuration, HAProxy can optionally do that, too, by negotiating a separate TLS session with the back-end, independent of the TLS session with the client, and using different certificates. Unlike the external-facing certificates, these back-end certificates can be self-signed, since the client does not see them.
In short, while sniffing the SNI and passing through the TLS from client to back-end is possible, it removes your ability to use HAProxy's full potential, so is probably the path to choose only when you have a specific reason to choose it.
You are correct that SNI only exposes what might be called "metadata" -- not the actual encrypted payload -- the concern here is that the hostname of the web site the user is visiting is not information that is kept secret if the traffic is intercepted... but this is true regardless of which way HAProxy is configured, because SNI-capable clients send it autonomously in their initial interaction with the server -- the server doesn't advertise this capability.
