Rock paper scissor game in Python
There is a lot of room for improvement in your code.
First, I'd like to address an unusual request you made:

Please don't recomend using functions.

Why not? They are a fundamental notion in programming, and can't really be avoided. Glossing over the fact that you already use a bunch of functions like print, input, append, etc., and assuming you are referring to functions that you define yourself in the code, it is still a puzzling request. Functions can make your code cleaner, easier to read, easier to maintain and more reusable, so why would you want to avoid them?
Take for example the part of the code where you ask for user input: the same code is copied and pasted twice. There are improvements to be made to that snippet. Implementing one these improvements would mean changing the code in two places. If it were encapsulated in a function, you would need to make that change only once, reducing the risk for errors.
Also, when reviewing your code, or when re-reading it yourself for further reference, encountering a properly named function is likely to be easier to process than what would effectively be the body of the function. I could see something like ask_for_input(player1) and focus on how the game move in handled, and then check out how you approach asking the user for input, independently from the previous logic. You could potentially reuse your ask_for_input function as is in future projects. Finally, you could then trivially replace the ask_for_input function with some sort of computer player if you want to expand this program.

As for the rest of the code, I won't provide a functional code, as there are already a lot of reviews on the site for &quot;rock-paper-scissors&quot; programs in Python. I'm sure you can find good, clean code that fits the bill.
However, I'll address a few design choices you made that can be improved upon, in no particular order.
Naming conventions
The PEP 8 Style Guide for Python Code recommends naming variables in lowercase snake_case, and constants in ALL_CAPS. Your variables and constants names are a mix of snake_case and CamelCase. While you may chose not to adhere to PEP 8 (although it's good practice to keep your code consistent with what is expected), at least pick a convention and stick with it.
PEP 8 is also a comprehensive style guide, and include cases that you may not even have thought about (like using a different style for constants, making the identifiable at first glance), so it is at the very least an interesting read.
Main loop
Most of your logic is enclosed in a while loop:
while True:
    ply_round += 1
    # ...
    if ply_round == 5:
        break

A while loop is clearly not the best fit here, as you effectively iterate over an incrementing index. A for loop would be functionally the same, while eliminating some overhead:
for ply_round in range(1, 6):
    # ...

Or better yet, use a named constant or a variable to specify how many rounds are played, so that you can see at first glance what the number means.
enumerate
You use enumerate a lot in your for loops. enumerate returns a tuple of (index, value), and you usually just use one of them. Instead of using enumerate, use for item in list if you only need the item, or for i in range(len(list)) if you only need the index.
Some times (although it is not your case here), you can't avoid using a throwaway variable. It is common practice to use _ in these cases, clearly showing that you don't need that variable.
Sanitizing inputs
When getting user input, you should check if the inputted value matches what the program expects. In your case, the program expects on of the values r, p, or s. If the user enters anything else, the program continues on and gives no output, while still incrementing the round counter.
This is made even worse because the prompts first ask for R, P or S, then for Rock, Paper or Scissors. The user has no way to know what the expected input is.
At the very least, you should change the prompts to ask for the correct value, and use .lower() on the inputs, so that the case doesn't matter. Then, if the value isn't what is expected, discard the value and ask again, instead of silently accepting wrong inputs.
At this point, you should really put the input code into a function, or else your program will get absolutely unreadable.
Backwards logic
Consider this piece of code:
for j, v in enumerate(choice):
    if choice[j] in ply_1:
        print(f'you choose {choice[j]}')

Ignoring the enumerate issue addressed earlier, what happens here is:

you loop over accepted inputs
check if the accepted input is in the actual input (which should be 1 character long)

It makes much more sense to do this the other way (check if the actual input is in the accepted range), and it's simpler too:
if ply_1 in choice:
    # do something

Winner determining logic
To determine which player wins, you basically check every possible case individually. That is a lot of code for a rather simple task. In fact, is is about on fourth of your code, and you only handle the most basic case of 2 players and 3 weapons. What if you wanted to improve your game to allow for more players or more weapons (think &quot;rock-paper-scissors-lizard-spock&quot;)? Then it would become absurdly long.
Possible solutions can include a lookup table, a dictionary associating each weapon to the weapon it beats, implementing a Weapon class with comparison operators, or maybe other things.
At the very least, you can check for ties with if user_Ply[0] == user_Ply[1] instead of comparing both to multiple common values.
Using a list instead of multiple variables
I feel like two variables, named for example player_1_move and player_2_move, would be more readable and more suited than putting them both in a list.
Anti-cheat measures
Player 2 can see what move player 1 made, making it trivial for him to win every round.
I'm aware that this is a programming exercise and no-one wants to actually play rock-paper-scissors on a terminal, but clearing the console would simply make sense to me.