I am probably misunderstanding the thread I linked to in my OP but reading through it (I remembered seeing this a while ago when I read your question) I got the impression that the LibreSSL guys looked at it from the opposite angle.
From my link:
TLS_FALLBACK_SCSV is only useful in the case where a client willingly chooses to do a downgrade and attempts to establish a second connection at a lower protocol after the previous one unexpectedly failed. In short, the client should not do this - client-side fallback is dangerous ("a landmine" to quote agl). TLS_FALLBACK_SCSV only works if both ends support it and it is largely a case of adding a workaround to support/enforce insecure behaviour. Unless you control both ends, you cannot be sure TLS_FALLBACK_SCSV is available and if you do control both ends you can either force TLS 1.2 and/or avoid client-side downgrade.
And the final reply: Server-side TLS_FALLBACK_SCSV support has reluctantly been added to LibreSSL.
I guess in the end the reluctance is more about it being new and untested and not so much a bad security practice.
[1] https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00
https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-05
A client sends a ClientHello trying to connect with TLS 1.2, MITM does not let that through, the client sends a ClientHello for TLS 1.0 with a signal that means "this is a fallback", the MITM lets that through, the server sees this and does not allow a connection, foiling the attempted downgrade attack.
I know that, that's why I asked: "Why is SCSV a sucky feature?".