"and at some point I'd like to make some code in C that resembles the source code of the game."
That is rather on the ambitious side for someone new to all this. If you are already a bit familiar with C and X86 ASM I don't see why you can't get hands on with some assembly stuff rather than doing the usual path of file analysis, text editing, graphics editing, cheat making and such before finding out that assembly is good stuff and makes a lot of things easier, or opens up certain avenues, but there is jumping in at the deep and and in this case going to swim at night in rough sea conditions.
As far as end users ending up with source code of some form then 3 ways that ever happens
1) The dev releases the source in some fashion or there is a leak, can also be of a substantially similar game (same engine, sequel knocked out for a year later...).
2) Someone does some combination of assembly fun, file analysis and game observation. This, especially if limiting to observation (see clean room reverse engineering), is usually a years long effort even for skilled programmers doing it for simple games. Or indeed pick anything that is not 1)* on https://osgameclones.com/
and see how glacial the pace is.
*I will note such sites tend to shy away from code leaks and things where the source release was retracted ( https://github.com/github/dmca/commit/ada33178ba1e9496453e18e097634a2fefa45e87
, bink/rad tending to be the main thing that sees such things happen or prevents game code from being released in the first place by otherwise willing devs, though video is a problem in general https://www.gamasutra.com/view/news/170671/Indepth_Playing_with_video.php
3) Was for quite some time treated as impossible (see halting problem) but owing to the way older C compilers work (don't know if this would be C++ which is probably a bit further out) and with some occasional lucky breaks (see Diablo function names being included in I think it was a Japanese port) then actually it is possible and we have things that compile to the same code as the original for a handful of games (Mario 64 being the most notable at this point, though some might opt for Diablo instead). I don't know what we have for PS2 efforts though; indeed the N64 thing came as a bit of a shock to me as I thought it was mostly still certain noted X86 C compilers that were the main things people looked at.
I am also not sure if anybody. much less anybody around here, has pulled apart enough PS2 games** in this manner to make some kind of what to expect, or what to expect of this vintage game (different years seeing more compiler development, different attitudes to security and devs pushing things further and further).
**there are some dealing in various consoles, or for consoles that were more extensively looked at (be it at the time or for emulation since), that can give you a timeline of when different protections where introduced, when optimisations happened, when compile versions changed, when base libraries were changed. Seen some fairly advanced stuff for the PS2 (mainly as the code was fairly advanced -- once saw a writeup of a PS2 text engine which had all manner of features that would impress even today for a typesetting program) but never the equivalent of that, or even an weird things and oddities list. That said I could easily have missed such a thing as PS2 is far from my main interest.
As far as what you can expect to find. I am somewhat surprised you have what looks like a full function name there; while elsewhere in this I will discount the optimisation done by compilers for the console and era it was still fairly common for such things to be scrubbed for security or optimised away.
On finding a NOP I would consider two main things. 1) Compilers of the day were still not as fancy as today's optimising efforts and a commented out function could well still be compiled but references to it blanked out. 2) NOPs are also used for timing purposes, that might even be their primarily "legitimate" function.
Address being generated at runtime is a possibility (we are well into the era of dynamic allocation by this point) though, as is some kind of external list to spare devs having to recompile every 5 minutes for a small change, though library loaded when needed is a better bet (afraid I don't know much about the PS2 approach here for dynamically loaded code and it is not like the PS2 is running much of an OS or hypervisor underneath it all).
Main functions in games regardless of system tend to be treated on a game by game basis -- some will be absolutely minor stubs that defer to other things almost immediately, others will be a true main function/core loop that the game does.
"which i presume is the binary"
Why not check? Disc based stuff overwhelmingly copies data, especially executed code, to RAM before use. Snatch the code (usually have a nice "currently executing instruction" you can watch for a while to see at least some of the main loops or basic bootup IO stuff) from RAM and other than compression (debatable if useful on a game where you otherwise have a whole DVD of space and 1 second of video or audio probably equals as much space -- force of habit, anti hacker or between disc read speed and whatnot it is still faster to decompress being the reasons to see it on a device like this) it should be the same as the disc. Can also spare you spending time looking at a debug binary the devs left in when packing up the game or link cable effort (not really a thing for the PS2 compared to the PS1, GBA, DS and many other things). Though yeah Sony does tend to trend towards the ELF format for things rather than fully custom (PE -- exe, xex, xbe, dll... being a Microsoft thing and all) so good shout on that one.
"with ps2dis and started scrolling through the assembly code to make some sense of it"
I am not going to say static disassembly and going in cold will gain you nothing but generally nobody does it unless they have to beyond a sanity check to make sure the disassembler's output looks like code. Find some aspect (would have said thread but... yeah) of the game you can use as a jumping off point (infinite health cheat***, main loop, main loop for the menu...).
***a list of notable RAM locations (seen enough of PS2 cheats, and https://github.com/mlafeldt/ps2rd/blob/master/Documentation/code_types.txt
does little to say otherwise, to know we are not yet in the era of all pointers, all the time or fun with ASLR) such that you might find for the average list of cheats can be a very nice thing to have here.