The other is a bit more "confusing" at first but once you have done it a couple of times it's not bad.  We break the code up into chunks and then wrap each chunk inside of an if statement with a code.  Then at the top of the program is our logic and that logic calls the code that is to run next so something like this:

Before Start Section
codeblock = 0

Program Section

whatStepToDo = "Get User Input as to what step needs to be done"
if codeblock == 0:
  switch whatStepToDo:
    case 1: 
      codeblock = 100
    case 2:
      codeblock = 200
    case 3:
      codeblock = 300
    default:
      codeblock = 0
  end    
end

if codeblock == 100:
     Do whatever unique thing you want to do here
     codeblock = 400
end

if codeblock == 200:

   Do some other unique thing here

end

if codeblock == 300:

  Do something even more unique here

end


if codeblock == 400:

  This is somehting that can be called from anywhere so needs to be at the end of the program, this could even call another subroutine so long as it appears below this one in the program

end

The biggest challenge with this style is that you have your logic at the top of the program and then all of your subroutines below that both physically and numerically.  There is no goto in the UR language so you can't jump back up to the top for instance and go from code block 200 to 100 unless you control how you reset going back to your starting logic blocks.

The part that we really like about this is it provides for a lot of reusability in our code.  We have program templates that we use for our deployments that already have defined a number of code blocks that get used in every deployment.  Also, once we solve a problem it's really easy to copy and paste it into another program for use there such as a block that takes in the current location and then does a spiral or helix move from that location.  Another big advantage is that it makes it easy to do testing of the code, we can make the robot just use one code block for instance so that we can check all of the motion and verify that it is doing exactly what we want it to do.

I have obviously oversimplified the starting logic as there is only one thing that it is doing and it's asking a user for it.  We have a round robin testing scenario where the robot is using up to 3 testers at the end of the line to test product and is keeping track of which tester to service when as well as determining if the part that was just tested needs to be retested on another tester, discarded down the reject chute or placed on the outbound conveyor to go to packaging.  All of this logic is being handled in 3 logic steps at the top of the program and then calling all the required move steps based on what the logic tells it to do.

This is how we have gotten around using subprograms and it has created a scenario where it is much easier to test the code, start from multiple places based on user input during the start-up sequence so that we can resume operation where we left off, reuse code in other programs and create templates that provide core functionality without us needing to do that everytime.