I'd like to add to MEJHarrison's excellent answer, by saying that "worth refactoring" also depends on the point of the project. This is a learning project so it's worth exploring and thinking about ideas, but the end result is throwaway code anyway. Strive for good solutions, but it doesn't need to be maintainable for decades.
I code differently if I'm making a quick one time script to change the way data is structured to use for something else, than if I'm coding a long-term project, like the Civilisation-Like game I'm working on these days.
For learning projects like this, absolutely consider various solutions and work to make your code the best it can be, but the ideas and thoughts are more important than what you end up leaving this specific code base at. In a few months you'll have developed many more new ideas about how you code anyway.
Even though it's a STEM subject, programming isn't so rigid with styling rules either. You might initially find that solution A is the best to solve your problem. Then when the project grows and evolves, you suddenly need three more parameters and you find that solution B is better, even though you initially decided against it.
In Swift Playgrounds like this, once you move to the next challenge, the previous code is probably pretty irrelevant. In a production environment where your codebase grows over time, your new code will interact with old code all the time, and whenever you do something that means you find a need to look at your old code, you have a chance to consider if the solution you picked then is still the best for the issue at hand.
I often start off with a class with a simple constructor taking a few arguments, suddenly it takes 6 arguments and I decide to make a Factory for it. I may start off hard-coding to a specification. Then the specification changes and it becomes a Strategy Pattern instead.
To quote a programming mantre; "I make horrible sins to make the code work... Then I clean it up and check that it still works" (from a book on Test Driven Development).
If you work in a larger codebase, there are also more factors to consider, such as "Is a similar problem solved elsewhere?" If so, your new implementation should do it the same way. That is, if it's identical, don't reimplement it. You want to avoid duplicated code. But similar things should be done in similar ways.
