You are correct that parfor will run as a serial for-loop without Parallel Computing Toolbox. Starting in R2021b, parfeval will also have a similar behavior, where the code will not fail if share with someone who does not have Parallel Computing Toolbox.
You have a few possible options available to you. You could write your code using parfor and share that code with users. The code will not error out for those who do not have Parallel Computing Toolbox, but will run slower. The thing to watch out here for is how you are starting the parallel workers; if you are starting parallel workers with the command 'parpool' that will cause an error if someone does not have Parallel Computing Toolbox. You could either 1) use backgroundPool in-place of parpool 2) let parfor start the parallel workers automatically (meaning you do not use parpool or backgroundPool and parfor initiates the parallel pool) or 3) you have a try/catch statement or something along those lines with parpool. I would consider your options in that order.
Alternatively to parfor, you could use parfeval if your simulations take different amounts of time to run and you want to optimize their scheduling or if your code can do other things while those simulations are being processed. Parfor blocks MATLAB from doing anything else, while parfeval computes things in the background on the parallel workers, so you can continue to use MATLAB for other things. The comment I made up top about parpool applies here, as well. The nice thing about parfeval + backgroundPool is that if you give that to a user without Parallel Computing Toolbox, parfeval will run in the background (on a single thread) without blocking MATLAB.
You have a few options available to you, with some being more intricate than others. You could share parfor and parfeval code with others without worrying about the code erroring. You can let parfor/parfeval automatically use Parallel Computing Toolbox or use backgroundPool to have a bit more control.