Openness, courage, and collaboration are foundational to effective agile adoptions. Anonymous complaints, suggestions, or concerns are often a symptom that this foundation is either missing or broken.
If you have a Scrum Team where the team members don't feel safe expressing opinions within the team, or don't feel empowered to address process issues head-on, then you have an existential problem with your Scrum implementation. This is most often seen in high power-distance cultures and organizations.
There can certainly be exceptions that would justify a specific problem being brought up privately. Some examples might be sexual harassment, bullying, or other issues that are more personal or interpersonal. Such issues could certainly fall outside the scope of the project and its processes. In such cases, the Sprint Retrospective is probably not the right venue for addressing those concerns anyway.
However, most project and process issues are whole-team responsibilities. Mature Scrum Teams are expected to collaborate as part of the empirical inspect-and-adapt process, and have the courage to address hard problems together.
Don't Confuse Techniques with Objectives
In Agile Scrum Retrospective boards, what is the best practice?
I'm not sure what "Agile Scrum" is supposed to be, but the official 2020 Scrum Guide has very little to say about how you must implement the Sprint Retrospective. Using boards with index cards or Post-It Notes is just one of many possible techniques. It's a means to an end, not a mandated practice of the Scrum framework, and not one of the framework's defined artifacts.
The purpose of the event is pretty straightforward, and is summed up in a single sentence.
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The activities required by the event are not highly prescriptive. The guide simply says:
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved...The Scrum Team identifies the most helpful changes to improve its effectiveness.
Note the emphasis on the whole-team approach to inspection, discussion, and problem-solving. Those things are hard to do when process issues or team collaboration problems are raised anonymously.
Don't Violate the Scrum Values
Furthermore, a persistent need for anonymity would violate the five core Scrum Values, especially the last three.
In fact, the guide goes on to say (emph. mine):
The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, [and] to work on tough problems [together].
If these values aren't being embraced by the team, then that's a process or implementation issue that should be discussed. It may not be enough to do so in a Sprint Retrospective. It may be a big enough issue that the need for coaching or root-cause analysis needs to be made visible on the Product Backlog, and time carved out of one or more Sprints in order to address it properly.
Don't Create Processes That Violate Basic Scrum Theory
If the Scrum Team lacks the openness and courage to discuss process issues forthrightly, this not only fails to embody the framework's values, but it also violates one of the core pillars of Scrum Theory: transparency. The guide admonishes practitioners that:
Artifacts that have low transparency can lead to decisions that diminish value and increase risk.
An anonymously-populated retrospective board seems like an artifact that intentionally lacks transparency. The Scrum Team should collectively determine why doing it that way increases value or reduces risk. If it does neither, then it's an anti-pattern.
Basically, this all boils down to saying that Sprint Retrospectives and the framework in general are designed for committed self-starters who are willing and able to work together to solve process problems and continuously improve their working agreements with one another. If they can't or won't do that, the problem is much bigger than whether or not the team members are visibly placing stickies on a board or prefer slipping folded pieces of paper into a suggestion box.