The thing missing from this analysis is how hard things will be to change later. If it's an internal function called in just one or two other files maintained

The thing missing from this analysis is how hard things will be to change later. If it's an internal function called in just one or two other files maintained by you our your team, then no need to spend a lot of time thinking too hard about it -- just write it as simply as possible, and then rewrite it when you find it no longer suits your needs. If it's going to go into an storage schema (database, json, whatever) which will require data migration if we need to refactor it -- or if it's an library that will be used by large amounts of code maintained by other teams or other organizations -- then it's worth spending a bit more time designing it. You're balancing the risk of wasting effort over-engineering it against the risk of the effort invovled in having to modify it later. If it's going to be a public interface used by customers and supported indefinitely, then you'd better be very careful about getting it as close to perfect as you can, since now you're balancing the risk of wasting effort over-engineering it against the risk of having to support a terrible API for years.