Pretty much echoing what everyone else is saying.. but I wanted to point some additional things out:
• Point 2 is not scalable. If further metadata is added to the model then this could spill over the 1MB limit and cause you a big pain when refactoring to fix this issue later on.
• With Point 1, for the best user experience, it will require a bit more work up front but worth it.. where you would expose a single load API via your repository/manager pattern, which fetches the item from cache/local DB, and probably kicks off some refresh/download of the item from your backend. Unless this data is client side only which makes it even simpler...
• As someone mentioned before, point 1 provides easier integration/support with deep links, plus allows you to pass in additional configurations that may be needed later on without risk of spoiling over the argument size limit
• Last point I can think of (1:30AM and I'm having trouble falling asleep haha)... but passing around in-memory objects like this can become an easy source of bugs later on when maintaining + adding new features. An example is where you pass in an in-memory object, and then based on user action or something similar, the data source should get updated. You would then need to properly manage updating the in-memory object in addition to saving the changes to your local DB or backend etc. Whereas providing a more "single source of truth" and always passing ID and fetching the model via your repo, allows you to more easily manage updates from both directions up to your UI state, along with the case where the view possibly gets destroyed than recreated.