In order to understand the threat from Meltdown, you need to understand how memory is organized in modern computers.
The naive view of memory is that each memory address corresponds to a specific set of cells in RAM. This is called "physical addressing", and until about the early 1990s, was the most common way of handling memory in a computer. Under physical addressing, if your program reads a byte from address 17, it's reading from the same set of eight memory cells each time. Turns out, a "physical-only" way of addressing memory rather limits what you can do, particularly with regards to running multiple programs at once.
Enter "virtual addressing". Now, your program's "memory address 17" no longer corresponds to a specific part of physical memory. Instead, when the CPU wants the data from that address, it asks a component called the "memory management unit" (MMU) which, in cooperation with the operating system, figures out how to fulfill that request.
This permits a number of efficiency and capability gains. The best known is probably "swap", commonly known as "virtual memory": address 17 might be temporarily stored on disk, and your program's request is put on hold while the OS stores the contents of part of physical memory to disk, and then loads the piece that your program thinks of as "address 17". Since the range of available virtual addresses is typically much larger than the amount of physical memory, this lets the OS give the appearance of a computer with far more RAM than it actually has.
The biggest gain from virtual addressing, though, is also entirely hidden from the typical user: it lets the OS give each program the illusion that it's the only program running on the computer. Your program's "address 17" isn't the same piece of memory as some other program's "address 17". This means that programs don't need to worry about hiding secrets from each other: Javascript running in your web browser, for example, can't read the contents of your password manager's memory.
For efficiency reasons, the Linux kernel assigns half the available virtual addresses to itself in each program's view of memory, and assigns all of physical memory as part of that address range (the Windows kernel does similar things, though the details vary). This lets the kernel access anything it needs to without having to adjust the MMU. The kernel then protects its address space so that an ordinary program trying to read the memory will crash.
Enter Meltdown: it lets a program indirectly read kernel memory without crashing. It's much slower than direct reading (typically around 150 kilobytes per second, where direct reading is measured in gigabytes per second), but it bypasses the protection. Because all of physical memory is mapped into the kernel's address space, an attacker employing Meltdown can break the "I'm the only program" illusion.
An ordinary desktop user doesn't have many programs that need to keep secrets from each other, and doesn't run much untrusted code -- the only major threat from Meltdown is hostile Javascript reading the contents of their password manager, and the details of how Meltdown works make it hard to use from Javascript.
The big threat from Meltdown is to cloud and shared-hosting providers. These computers routinely run programs from untrusted users, and depend on the "I'm the only user" illusion to keep things safe. Meltdown lets an attacker with an account break this illusion, and do things like steal other users' SSL private keys, usernames and passwords, payment-processing credentials, and other sensitive information.