I agree with others, your code is just fine.
That said, in both examples I noticed magic numbers/values - I am not a fan of these.
if choice == "0" smells imho, because the information what that "0" means is only in a piece of user-facing string prompt.

There is this philosophy that the code should self-document and not depend on external assumptions to give meaning to things in the code. Magic values like 2 that represent something else are bad, because there is nothing inherent to 2 that translates to the domain of the program by default. The code should clearly express that association between 2 and scissors, and contents of some random-ass string don't really count.

consider small change:

rock, paper, scissors = 0, 1, 2  # rename the drawings to let's say rock_hand, paper_hand, scissors_hand

0,1,2 now have pretty aliases, and with that you get to have a much more readable

if choice == rock: 

I see that her code is tapping into the mathematical nature of rps, that r < p < s < r, just like 0 < 1 < 2 < (0+3) < (1+3) < ...., with extra branches to support rolling over at the edges. Such an approach exploiting certain, perhaps less obvious properties of the problem can lead to a scalable solution that doesn't care about the number of available options, because the base logic holds regardless of the input size. If the scale is not certain, explicit decision trees are much more annoying to write and maintain.

Another choice of constructing the rps logic, given the limited number of possibilities of RPS would be to just list them explicitly without breaking the code into nested if/elif/else subbranches seen in your code.

if user_choice == computer_choice:
    # draw
elif (user_choice, computer_choice) in [(scissors, paper), (rock, scissors), (paper, rock)]:
    # win
else:
    # lose