Yeah, but both pages are doing the exactly same thing ...
This is just a style difference. The system will read from whichever files are in that folder. Putting the realtime lines into limits.conf or 99-realtime.conf makes no difference. 99.realtime.conf is a good idea in that it won't be replaced if the main limits.conf if altered on a system update. Also, the groupname you use is arbitrary, "audio" or "realtime" will work either way (but don't mix them).
There is lots of info out there but I think, perhaps, you're confusing yourself and/or somehow missing, conceptually, the point of all of this. I don't write that in a bad way as I went through the same thing when I switched to Linux. It's easy to start following articles and forums at first the tweak this and that ... but in the long run you just have to learn the *why* of what you're doing and not just the *how*.
Let's look at Pd + Jack. From my experience with Linux, (some of this may have been updated by now, but I don't think so), there are 2 low level audio APIS: OSS & ALSA. OSS was the original, but ALSA has the predominant interface for apps to connect to audio hardware. From a user point of view, it's main problem is that it does not do mixing of audio streams aka you can't open multiple audio programs and have them play sound together using only ALSA. You need something else to help out, enter ESD (Enlightenment Sound Daemon), Jack, & Pulseaudio which are simply software daemons running on the background that take audio streams from apps and mix them before sending the result to ALSA.
ESD & Pulseaudio are focused on the day-to-day desktop environment while Jack is mainly for professional audio work aka *fast, low latency audio*. This is an important difference. ESD & Pusleaudio are mainly just providing audio for your youtube video or music player, so you won't mind or notice that they buffer and run at a pretty long latency (say 1024 samples per buffer +, etc). A long latency means the cpu doesn't have to process that stream as quickly and the sound server (ESD/Pulse) doesn't need to run at a very high priority. Jack, on the other hand, is designed for *realtime* performance aka getting everything to process as fast as possible so you have the lowest latency possible, say a length of 128 or 64 samples per buffer. In order to allow Jackd to run as fast as possible, we have to tell the system that it should have the permissions to receive more resources and run faster than other apps, hence needing to unlock the realtime limits.
Ok, if we can now run Jackd in realtime mode, we should try and run our audio apps as fast as possible as well, if they support it. Why? Because, they may not be able to deliver the samples as quickly as Jack wants, resulting in audio dropouts (clicks). For Pd, there is the -rt start flags which starts Pd with realtime priority. Again, needing this really depends on your system, but it's a good idea to run Jack & Pd with -rt, in my experience. Years ago, I happily ran realtime audio with Jack and multitrackrecording from Pd to Ardour on a *single core* Pentium M with around 1.6 GHZ which was a beast compared to the early 2000s, but is a mouse by today's standards.
Aha. Well, welcome to Linux ... :D In the future, though, it would be helpful if you did that before trying to get the pd-list to help you step by step through the process. They coudl be doing other things, like improving pd :D On the other hand, perhaps there is not the *right* info out there now and perhaps we need to have a How To Jack + Pd added to the Pd FAQ?