I haven't seen a base story for a while now. It was great for me in the onboarding processes, especially when the team was already formed and I was "the new guy", but after a while I god what a 8 meant for them, a 5 and so on. At first I was pretty upset that they wanted me to estimate, without knowing what they were expecting (since we had different numbers for the same thing). In the end a story point is not man days, so it can't really put as: 16 hours means 1SP. After a while (basically after working in some Agile projects), I realized, it's pretty hard sometimes to have a base story. Let's think about vertical slicing. You need a create a page in the UI with a form (write the code for the page and form), call a server (write the endpoint and logic), save in a database (create new tables). This is the simple example that I can get. If you always have UI+API+DB it's easy, but if you usually have different types of changes (maybe 3-4 stories only UI related, 40 API related and 22 Db related), how can you create a base story? And even if you make some sort of calculation and get somehow to a base line here, how will you manage when you don't have only 3 components, but you have 5-6 (or if you are using microservices, maybe more) ?

Anyway, right now, I am a huge fan of "no estimations", and I really have the same opinion as you, regarding the purpose of the planning. It should be only for helping the team understand what they plan to do in the next 2-3-4 weeks (or whatever the timebox of their sprint is). Scrum is a development framework not a management one!