No. Package.swift declares to clients what the package is compatible with, whereas Package.resolved declares to contributors what the package should be developed with.
For a root application, the difference is irrelevant, since only one resolved graph is ever relevant at a time. Specifying exact dependencies in Package.swift best represents your intentions for your code. At that point, Package.resolved is entirely redundant and ignorable.
For a library, the difference is extremely important, because narrowing the ranges in Package.swift increases the odds of ruling out a sister library from being used alongside yours due to conflicting constraints. To be most useful, you generally want your Package.swift to declare ranges that are as wide as possible. When your Package.swift is full of ranges, then you need a separate mechanism to ensure that your testing is consistent and actually tests what you think it tests. That is what Package.resolved is for. Due to the meaning conveyed by semantic versioning, if you pin at the bottom of a range and it works, you know that it also works with later versions. The reverse is not true; if you pin at the top, you do not know if it actually works with earlier versions. So the precise pin you choose makes a big difference. As a library developer, you need to prevent inadvertent updates during development (.resolved), while permitting newer versions when used by clients (.swift). So you need to consciously craft, audit and track each file separately.
With regards to whether or not one ought to explain all this to clarify the context when recommending committing Package.resolved, it is usually more words than it is worth. For an application, the pins file is irrelevant, not counterproductive. So any effort put into learning the pattern or into registering the file as ignored in certain cases is wasted effort that gains you nothing. And the extra complexity in your recommendation might confuse the beginner. If you just commit the pins file all the time (as I do), you get all the benefits with no down sides. This is why SwiftPM’s templates have it this way.