I would say that one of the main reasons for doing a Lock & Roll is to provide a clear distinction between the code that was pre-upgrade and post-upgrade. Doing a pre-upgrade skim would achieve this. However, although it is recommended, a pre-upgrade skim is not mandatory. If a pre-upgrade skim is not done then I'd say a lock & roll takes on greater importance.
In your case, the lock & roll is not so key as your post upgrade code changes will be in a new major version anyway - and as pointed out above, you won't be able to lock your rulesets if they have been locked and skimmed anyway. Unless you want to use the lock and roll tool to a create a new application rule, I'd suggest you can skip this step and continue your post upgrade steps and future development in your new major version.
Following 2 points of your comment are CONDITIONAL.
*Rule zips (only incase of install-migrate approach) and the new Pega7 rule schema will be lighter.
*Upgrade.bat and migrate.bat might take less time to run hence less likely to fail. (only rules schema)
The condition is , after you skim to a Higher Major version, you need to delete all the older versions from the prior major versions and test & Verify. Until, you do this, your Rulebase is NOT lightened and hence might take more time for upgrade.
As a pre-upgrade step we performed a major skim for all the existing application rule sets from 01- to 02-
When we were about to delete all the 01- rule sets we realized that all the Rule-Obj-Class definitions are still associated with 01-XX-XX rule sets; most of them in 01-01-01. So skims do not accommodate Rule-Obj-Class definitions; since they are only associated with a rule set version for portability and are not rule resolved ?
Kindly post your views and suggestions to tackle this situation.