Multiple implementations is also good for standardization; in a monoculture, the dominant software becomes the standard, giving the developers of the dominant software a higher degree of control over the future development of the protocol than was originally intended. This does not even require the developers to make a conscious decision to start subverting the design process for personal gain to be harmful; even if, as is almost certainly the case today, developers are acting with the best of intentions there is a bias in software development toward increasing complexity and confusion that is mitigated if multiple implementations have to work together on every change. If there is only one implementation, errors get uncovered later rather than sooner, and the result is a sort of Talebian “stability breeding its own instability” that ultimately, as in the case of the March blockchain fork, causes disaster. Additionally, developers have no incentive to even document the protocol as long as it works internally. Currently documentation does exist on the Bitcoin wiki, but with multiple implementations we can be much more certain that the page will be updated, and even improve in quality, in the future.
Whether or not btcd will actually be used by miners is hard to say; it is entirely possible that miners will remain comfortable with the existing bitcoind, and the stability through decentralization that a healthy ecosystem of alternative implementations can bring will never come to pass. But even in such a state, this will still be a step forward for Bitcoin if only because it makes it easier for Go users to interact with the protcol. A Bitcoin implementation in Go has already been written, but it has not been updated in nearly a year, and appears to have only ever had a single developer behind it. btcd is backed by a corporation that is clearly well-versed in security and privacy, inspiring much more confidence in its reliability.