Scrum team starts working on stories part of current release but scheduled for upcoming sprint

Some Scrum teams in my organization start working on stories which are potentially part of the release, but not part of the current sprint.

In Scrum, shouldn't the work completed every Sprint be potentially and immediately releasable?

You appear to be using a non-Scrum framework while using Scrum terms. This has confused the situation and reduced transparency. Scrum behaviors and outcomes cannot realistically be expected.

Ian Mitchell is right in that using Scrum terms but not using Scrum is confusing. The terms come with definitions and expectations that may not be met, which makes it hard to have a conversation that aligns with what you are actually doing.

However, a few things that you say do stand out:

• I'm not convinced of the value of any kind of long-term planning, whether that's "quarterly planning" or SAFe's "Program Increment (PI) Planning" or anything that looks out more than a Sprint. Every iteration should have an inspect-and-adapt period which could cause your longer-term planning to be invalidated.
• The idea that people work in silos and "senior" team members are the ones who review the work are antithetical to a self-organizing, cross-functional team of equals. Has the team actually experimented and given pair programming and mob programming a chance? Admittedly, it's not for everyone, but it does work for many teams. I'd also point out that reviews are a good way to learn, not just to find mistakes or errors. I've previously written about different reasons why you would want to carry out a code review.
• There are inherent transparency issues with working on things out of the Sprint. Mainly, you don't know how long it has taken or how much effort has been spent. This makes it hard to determine capacity and give any kind of reasonable forecast. Overall, this would harm empirical decision making.
• People working on things that have not been selected for the Sprint seems to indicate a lack of focus and commitment to the current Sprint Goal. I believe that this is something worthy of discussing at a Sprint Retrospective to understand why the people who do this feel that it is appropriate.

I don't think the problems are around visualization, but focus, commitment, transparency, and empirical decision making.

Some Scrum teams in my organization start working on stories which are potentially part of the release, but not part of the current sprint.

But on day 1 of each Sprint, few members start working on stories which are potentially part of the release, but not planned for current Sprint.

@Jaysmika Patel, Why do they do that?

And, don't think that all stories can be completed in the same sprint.

Why? Do they have dependencies with other teams? If so, how can they minimize or eliminate those dependencies? How can they self-organize as multiple teams?

Are they using Sprint Goals every Sprint?

Also, since you mentioned SAFe, are all the Teams within your ART working on the same Product? or are they working on separate projects/initiatives?