The issue I have with this principle is how the strong opinions are presented. It's often not easy to tell the difference between "an inexperienced, non-authoritative, strong opinion weakly held" and "an experienced, authoritative, strong opinion strongly held".
If it's obvious that you're a junior dev -- that you have both little experience and little influence -- then expressing a strong opinion isn't really problematic, because other people will feel comfortable challenging it.
The problem comes as you start to gain experience and influence. As it becomes clear that you do have experience in general, then people are likely to assume that all of your strongly stated opinions are the result of experience, even when they're not. Thus people with a little bit of experience in X, hearing your strong opinion on X (even though you have zero experience) are more likely to discount their experience, rather than sharing their experience with you.
Similarly, people who are coming from the outside -- say, people from other companies talking to a team lead of a project; or contributors submitting to an open source project -- are more likely to hear opinion X as being, "This is the rule for this project", rather than "This is my current opinion, but feel free to challenge me if you think it's wrong".
So if you're going to hold strong opinions, you need to make it clear when you express them that they are in fact weakly held; and the more you grow as a developer, the more important it is.
I have heard of an anecdote that in some company, can't remember which, when meeting to take a decision, they would have people speak up in order of seniority, from the most junior to the most senior in the room. That way they could avoid the problem you're describing: you don't risk contradicting someone preceived as more experienced, or worse, your boss.
I found that an elegant solution, at least in abstract, I've never actually see it in practical use.
I can see how this sounds good, but my first reaction is that I think it is the kind of thing that would work great in a really good team that wouldn't even need it, and it would be awful for juniors in the kind of team that would get really excited about implementing it. Who wants to speak up when you don't know the ropes, you haven't gotten used to the social dynamic, etc? Seems to select for people with excessive confidence, who already have no difficulty advancing themselves.
This model seems insufficient and exclusionist to people who are socially withdrawn, or have a social disability, or come from a marginalized background, or any of the myriad reasons some developers already don't speak up. But it's a good starting point. I just would not implement it without additional frameworking to guide and encourage useful input from the juniors. In which case, if you're putting in the effort to understand why people aren't speaking more freely, this framework may be superfluous (or it could still be a valuable part of your practices).
If it's obvious that you're a junior dev -- that you have both little experience and little influence -- then expressing a strong opinion isn't really problematic, because other people will feel comfortable challenging it.
The problem comes as you start to gain experience and influence. As it becomes clear that you do have experience in general, then people are likely to assume that all of your strongly stated opinions are the result of experience, even when they're not. Thus people with a little bit of experience in X, hearing your strong opinion on X (even though you have zero experience) are more likely to discount their experience, rather than sharing their experience with you.
Similarly, people who are coming from the outside -- say, people from other companies talking to a team lead of a project; or contributors submitting to an open source project -- are more likely to hear opinion X as being, "This is the rule for this project", rather than "This is my current opinion, but feel free to challenge me if you think it's wrong".
So if you're going to hold strong opinions, you need to make it clear when you express them that they are in fact weakly held; and the more you grow as a developer, the more important it is.