If a "screen load" includes making a network request to fetch data, then this is a very weird metric to include in a post about React Native. Most of that time budget should just be waiting for the request to complete. Just as before, it should take <16ms to render the screen once the data arrives.
500ms sounds about right for a cold launch but otherwise is pretty poor.
50-100ms for "minor" screen changes and 100-200ms for "major" ones are otherwise reasonable for native screens.
Keeping UI rendering under 16ms is the gold standard for native apps. That leaves only deserialization as the other target which the mobile developer can optimize. However, the typical solution there involves convincing the backend to ship a different format (i.e. switching from JSON to binary PList or to SQLite DB file).
No, it isn't.
If you're not including the actual rendering, so the actual code of the app only or at least only the code on the UI thread, the targets are much smaller. More like 3-6ms/frame.
If you're including rendering then pipelining and 90hz+ being common still changes that anyway.
Not since they’ve started releasing 120hz screens.