The luceneMatchVersion parameter is primarily a tool to ensure consistent indexing and query behavior through an upgrade.
A new release could introduce a different behavior for the text analysis chain of certain field types(tokenizers, token filters ect..).
A bug in a tokenizer could be fixed or simply the way a token filter was working could be changed.
When upgrading your Apache Solr instance to X+1 version, if you want to keep the same logic as an old Lucene version X, to keep consistency with the text analysis chains you were using, it is a good idea to set such version X in the luceneMatchVersion.
When upgrading a Solr instance from version X to X+1, it is a good idea to deploy the new version with the <luceneMatchVersion>X</luceneMatchVersion>.
In this way, you keep consistency with the old index X and continue to index live new documents minimizing surprises at least for backward compatibility until you can afford to re-index.
As soon as possible you should proceed upgrading the luceneMatchVersion to X+1 and run a re-indexing.
This is because the new Solr can read up to a certain old index version, so existing index segments will remain in the
format they are while new segments will be written in the new format.
If any of the existing segments are merged because of the merge policy, then the new larger segment will be in the new format.
e.g.
If an index starts out as 6.x, then is run for a while in 7.x, but there are still 6.x segments left(not merged), then that index will not work in 8.0 (indipendently of the luceneMatchVersion)