If I had to keep only one Python data structure, I would keep the dictionary. Lists are useful, sets are useful, but dictionaries are the tool I reach for most often in real work, because so much of programming is really about looking something up by name.
A dictionary is a set of pairs: a key and the value that goes with it. That simple shape turns out to be remarkably flexible. I use it for configuration, where a setting name maps to its value. I use it for counting, where a word or an event maps to how many times I have seen it. I use it for grouping, where a category maps to a list of items in that category. The structure stays the same, even as the job changes.
Configuration is the clearest example. A small script often starts with a few variables scattered through the code, and then grows. Moving those values into a dictionary, with clear names as keys, makes the script easier to read and easier to change. When a setting needs to change, I change it in one place, and the rest of the code reads it from there.
Counting is another place where dictionaries quietly do the work. Instead of keeping parallel lists of items and counts, and trying to keep them in sync, I let the item be the key and the count be the value. Each time I see the item, I increase its count. The code is short, the intent is obvious, and there is no second list to fall out of step.
Grouping follows the same pattern. If I need to collect log lines by service, or files by type, or tasks by status, a dictionary with a list under each key does the job. I do not need a special data structure for each case. I need the same one, used well.
Dictionaries also make JSON feel natural, because JSON objects and Python dictionaries map closely to each other. When I read data from a web service or a file, it often arrives in a shape I can work with immediately, using names I already understand. That closeness removes a whole layer of translation that used to slow me down in other languages.
There are limits, of course. Keys need to be unique, so a dictionary is a poor choice when I genuinely need duplicates in order. And a dictionary with unclear keys is worse than no dictionary at all. I try to choose key names that explain themselves, because the next person reading the code, who is often future me, should not have to guess what a key means.
The practical takeaway is to start with a dictionary when the problem is really a lookup. Ask what the name is, and what belongs under that name. If you can answer those two questions, you probably have a dictionary-shaped problem, and you probably do not need anything more complicated to solve it well.
One small example stays with me: a script that read a messy list of records and needed a quick summary. Instead of building a class or a database for a one-off job, I grouped the records by a single field in a dictionary and printed the totals. The script stayed short, the result was easy to check, and I threw nothing away that I needed later.