You should be able to guarantee that your database can be validated in read-only mode if you use the WAIT BEFORE START clause. See DocCommentXchange. Rolling back transactions requires writing to the database file itself, not the transaction log. So, if there is an uncommitted transaction at the time the backup starts, the backup database cannot be started read-only.
If you do a step of applying logs with -ad, you may not be able to start up the database in read-only mode unless you also use WAIT AFTER END (which can be dangerous since the backup will wait indefinitely for all transactions to complete). The problem here is that the logs you apply may have uncommitted transactions in them. So, although the backup copy of the database file itself has no uncommitted transactions due to the WAIT BEFORE START, applying logs without WAIT AFTER END could introduce some uncommitted transactions.
Validating in read-only mode was primarily introduced to avoid the need to make an extra copy of the database in order to do the validation because once you start a backup in read/write mode, you can't use it for your recovery strategy. If you are willing to make a copy, you don't need to worry about read-only databases.
Whether you are concerned about the possible effects of events when doing validation is up to you. If this is a known database with known schema, your validation script could disable any events that could cause problems: the database is going to be thrown away anyways.