Does the exact distribution of padding bytes in PKCSv1.5 type 1 matter?
In practice this should be okay. The reason the padding needs to be random is that if the padding can be guessed then the attacker can start encrypting candidate plaintexts (correctly formatted with the padding) under the public key and observe if the output matches the target ciphertext. Of course if the attacker finds a match then they have recovered the plaintext.

If the padding is 11 bytes of purely random padding that can take any value in $[1, 255]$ this means the attacker will have to do $255^{11} \approx 2^{88}$ encryptions for every candidate plaintext they want to check, which is clearly computationally intractable.

By sampling in the range $[0, 255]$ and replacing $\tt{0x00}$ with $\tt{0x01}$ you still have $255^{11}$ possible paddings but there are now some bytes that are more likely to occur than others (e.g. the first byte is more likely to be $\tt{0x01}$ than $\tt{0x02}$) so the attacker could optimize the order in which they check encryptions of padding / plaintext combinations.

If you are deriving padding bytes via a LCRNG this can lead to much worse results since there are ways to predict the output of a LCRNG. This in turn would reveal the padding to the attacker and instead of $255^{11}$ guesses per candidate plaintext they would only need $1$. In a sense when the padding is known the scheme degenerates to textbook RSA, and as such carries with it the same issues.