As far as I can tell, "service discovery" means a way for a client to find out about a server (or cluster of servers) that it wants to connect to.
I've built web applications that communicate with other back-end processes using protocols like HTTP and AMQP. In those, each client has a config file that contains a host name or whatever information it needs to connect to the server, which gets set at deployment time using a configuration tool like Ansible. That's simple and seems to work pretty well.
Is service discovery an alternative to just putting server information in a client's config file? If so, why is it better? If not, what problem does it solve?
Let's start by reviewing what service-discovery is - here's a good explanation: https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/ (this link should pretty much clarify the issue asked)
And here's an example how it is used in practice: Suppose you have service B which is used by service A. Service B (like most services in SOA) is actually a cluster of applications of type B. Service A requires to use one of the nodes of cluster B, yet the cluster of B nodes is dynamic. i.e. B nodes are created and terminated, depending on the load on the overall B service. Now, we would like service A to communicate with a live B node every time it needs to use service B. In order to do so, we will use the service-discovery tool to provide us, at any given time, an address of one of the live B nodes.
So, trying to answer your above questions, putting the end-point server information (specifically endpoint address) as static configuration in a config file which is read at the startup of service A, won't give you the dynamics you'd like when service B endpoints may constantly change.