I'll answer your question with a question; when you drove to work this morning (I'll assume you did in fact do so), did you care exactly how the engine opened valves to let in fuel-air mixtures, and then ignited them? No. You don't care how your car's engine works when you're driving down the road. You care that it does work.
Suppose, one day, your car fails to work. Doesn't start, throws a rod, breaks a belt, inexplicably plows into that concrete barrier through no fault of your own while you were busy texting. Now, you need a new car (at least temporarily). Do you care exactly how this new car works? No. What you care about is first that it does work, and second that you can use the same knowledge and skills that you used to drive your old car to drive the new one. Ideally, it should appear to you that there has been no change in the car you are driving. Realistically, the way this new car works should give you as few "surprises" as possible.
These basic tenets are the core principle behind encapsulation and abstraction. Knowledge of how an object does what it does should not be a requisite to using it to do what it does. Even in computer programming, the details of electrical paths within the CPU running your program are abstracted behind at least half a dozen layers of I/O instructions, drivers, OS software and runtime. Many very successful software engineers write perfectly good code without once worrying about the exact hardware architecture, or even OS build, that will run it. Including me.
Encapsulation/information hiding allows the "don't care how it does, just care that it does" mentality. Your object should expose what is useful to the consumer, in a way that the consumer can easily consume. Now, back in the real world, this doesn't mean that a car shouldn't give the user any information about the inner workings, or that the car should only allow the user the most basic of functionality like the ignition, steering wheel, and pedals. All cars have speedometers and fuel gauges, tachometers, idiot lights, and other feedback. Virtually all cars also have switches for various independent subsystems, like headlights, turn signals, the radio, seat adjustment, etc. Some cars allow for some pretty esoteric user input, like the sensitivity of the limited-slip center differential. In all cases, if you know enough, you can open it up and change things to make it work a slightly different way. But, in most cases, maybe, just maybe, the user shouldn't be able to directly and independently control the fuel pumps from inside the cabin? Maybe, just maybe, the user shouldn't be able to activate their brake lights without actually depressing the brake pedal?
Abstraction allows the "this isn't the same as that, but because they are both X I can use them as I would any X" mentality. If your object inherits or implements an abstraction, your consumers should expect your implementation to produce the same or similar result as other known implementations of the abstraction. A Toyota Camry and a Ford Fusion are both "cars". As such, they have a common set of expected functionality, such as a steering wheel. Turn it counterclockwise, car goes left. Turn it clockwise, car goes right. You can get in any car in the United States and expect the car to have a steering wheel and at least two pedals, the one on the right being the "car goes" pedal and the one in the center being the "car stops" pedal.
A corollary of abstraction is the "theory of least astonishment". If you got behind the wheel of a new car for a test drive, rotated the steering wheel clockwise and the car turned left, you'd be pretty astonished to say the least. You'd accuse the dealer of peddling a POS, and would be unlikely to listen to any of his reasons why the new behavior is "better" than what you're used to, or how well this behavior is "documented" or how "transparent" the control system is. Despite this new car and all the other ones you've driven still being "cars", when driving this car you have to change some fundamental concepts of how a car is supposed to be driven in order to drive the new car successfully. That's typically a bad thing, and it only happens when there is an intuitive advantage to the new paradigm. Perhaps the addition of seat belts is a good example; 50 years ago you just got in and went, but now you have to buckle up, the intuitive advantage being that you don't go through the windshield or into the passenger seat if you get in an accident. Even then, drivers resisted; many car owners cut the seat belts out of the car until laws were passed mandating their use.