I have no doubt you're right about the thrust of your article - I have met (fortunately few) people like this.

However I'd gently suggest it highlights a few places where you might benefit from thinking about things a little more flexibly.

Good tickets are really valuable and you make some good points about this. As well as information for other people (or future you), this process encourages pause for thought. However, a fully fleshed out ticket relies on fully understanding the problem, and sometimes we don't yet. In those cases we need to do some work, whether a spike or production, to arrive at that point. Otherwise we're into classic pitfalls of waterfall. So, be agile about raising tickets and populating them with info.

Then there's merging into develop. It partly depends on your agreed processes, but you should be able to merge before a big phase of work is fully complete, and in general it can be OK for a product on develop to be broken (but compile) whilst work is ongoing. This is how you can complete features in small pieces rather than one huge PR. However, it's got to be agreed, highly organised, and the incomplete parts need to be tracked.

Similarly, raising a PR before it's complete, maybe using GitHub's 'draft' PR feature, can be really useful to surface work for discussion earlier, allowing earlier manipulation of it. There's nothing worse than raising serious comments on a huge PR where all the effort has already been spent.

Then there's some stuff you mention about Lint and it's an area that I find junior developers are much more bothered about than senior ones. Consistency is important, clear developer expectations are important, and the delivered properties of code - comprehensibility and maintainability - are hugely important. But there's a really easy trap to fall into here, arguing between developers about one-true-way or using code style to fight some battle that isn't really about the code. In my job I don't have much discussion about style any more - we have the IDE sort things to a certain degree but we just aren't that bothered about every last detail as long as people write sensible code. We care about the developed product and we care about looking after our engineers.

I mention the above to try and keep you focused on what really happened here: a failure of leadership and collaboration. Someone doing things a different way to your expectations is not the problem. If you're flexible and willing, then with the right senior developer and the right relationship, you should be able to figure out what's going to work for the particular situation you find yourselves in. Overall you sound like you're on the right path (and everything here is common amongst junior devs) and I'm sorry you've had a negative experience. Keep at it and hopefully you have a better experience next time.