Sometimes they don't translate to the company's core business at all. That's a fact.
However, at least some of the time, they are associated with a core business problem that the team, or the company, you're interviewing with, faces.
At one company I interviewed with, mostly known for helping users find a cost-effective flight, I was asked a couple of problems with roots in combinatorial complexity and in routing. One of them was an n choose k problem, which certainly can come up when you have a large number of sets and you need to enumerate all subsets of say, 1, 2 or 3 elements; there's at least a plausible case that finding all nonstop, one-stop and 2-stop flights might benefit from knowing how to solve the abstract problem. Separately, I was asked a 2D convex hull problem, which is closely related to a bunch of problems used in say, collision detection in computer graphics, some classes of image recognition and graphics-to-text transformation problems, and, in fact, certain classes of routing problems; they might as well have asked me about the minimum spanning tree problem, which has previously been used by, say, telephone companies to figure out where to nearly-optimally place telephone poles and switches and the like, and comes up in transportation problems as well.
In this particular team, I wouldn't have had any involvement in solving routing problems; I would have been mostly focused on internationalization work. But perhaps because of the culture of the organization, and their core business problems, these types of problems now pervade their software developer interview process, regardless of what you might end up actually working on.
Although I didn't do particularly well solving these problems, given my very non-algorithmic, non-academic background in software, I somehow was offered a job; I'm guessing that in some organizations, they just want to see you sweat, and see how you approach problems out of your comfort zone under pressure. In some teams, it might have actually been important to also solve the problem well, rather than just demonstrate your thought process.
While I don't think this is the best possible strategy to identify good developers, Google, Amazon, Microsoft, and dozens of other well-known companies have adopted the algorithm-heavy ritualized hazing interview process, so it may be unavoidable depending on where you want to work. You can prepare for them by reading Skiena's Algorithm Design Manual, which will help you pattern match concrete problems to abstract ones, and lead you to propose appropriate solutions, even if you can't implement them in an hour long coding interview.
If I were interviewing a candidate for a role that involved deep algorithmic knowledge, I would be inclined to probe by proposing problems that require them to pull from their algorithm toolkit. However, in most of my work, I focus mostly on finding candidates that realize why doing three layers of nested loops to issue separate queries to an external source one ID at a time is a bad idea, and try to find proof that they know how to do better than that. I focus on seeking evidence that they've figured out some sensible strategies for writing maintainable code, that they have intellectual curiosity, and that they have basic social skills. I try to verify that they've worked deeply enough through some problem that they've learned enough to be the local expert on it.
If you end up interviewing at a company whose business is built around solving some tough problem with the help of smart algorithms, there's a good chance they'll try to find evidence that you, too, can solve problems with the help of smart algorithms. I also think that, even if you end up writing "boring" enterprisey software, having a firm grasp on the landscape of algorithms is worthwhile, because you'll recognize insanely bad approaches when you see them and you'll step back and try to come up with better solutions. I've now seen a ton of crappy production code that basic computer science applied to the problem would have prevented.
Because of that, even though I don't find the algorithm-heavy interview as useful as some companies appear to, I am convinced that, if you can't see the connection between abstract algorithms and real business problems, the problem is, at least in part, you. You can get practice on pattern matching with the help of Skiena's book and by thinking about real world problems that you'd like to solve and implementing defensible solutions, so do that.
