This is a great question because it comes up a lot and might seem like a bit of a free for all, but there are ways to be a bit objective in answering! I will try to do this by sharing with you approaches that I have seen to be successful, and basing what I say on documentation and policy where it exists.
I don't know that there is a "standard" practice here. You're fundamentally asking about cultural norms, not legal interpretation (which you already know).
So it helps to think about responsibilities. This is where many open source developers experience conflict and express defensiveness. They want to help people, and have their package be used. But if they get burnt out or overwhelmed (PDF), they can't achieve that.
You have a responsibility to the users of the package (Ubuntu and probably Debian users) not to mess up their system, to provide useful software, and to respect their rights. You have a responsibility to Ubuntu and Debian not to decrease the quality and perception of their distribution. You have a very similar responsibility to the developer of the source package, plus to respect their time and effort. (The latter is what they've explicitly warned you about.)
(How did I come up with this list? Partly by reflecting on projects I've participated in, packages I've created, operating systems I've used... but also by repeated reading of the documents I link to, research on open source communities, and developer articles/blogs.)
The developer in question might be more likely to accept your offer and provide help if you can demonstrate that you are aware of these responsibilities. (They might not be, I don't know them.) You don't have to fulfill them all! But if you think about your actions in terms of them, you will probably have better luck.
So how can you, or others in a similar position, proceed? Well, let's work backwards.
How do you demonstrate that you respect the developer's time and effort?
Make it clear that you're a regular user of the software, and that you're "dogfooding" it ie. installing your own packages, from your own PPA, using it regularly — then they know you'll be the first to notice the most prominent issues. See below.
Contribute to the project! File issues, provide detail, do a bit of debugging yourself. Fix bugs if you can, small ones at first. Improve documentation. Help out with issue tracking and user support if you're able.
Document what you do! If, for whatever reason, you have to stop then good documentation means that there's a much better chance of someone else picking up the PPA maintenance. Here's a sample of what I mean, from when I left RabbitVCS. Share your config files. Your tips. Your bookmarks. Everything. As you go.
Hey, now that you've documented it... you could maybe document it in code form! That is, automate it!
Seriously, there is a world of difference between some random person asking for help with a PPA, and a regular helpful contributor proposing one. Random person: could increase a developer's workload. Regular: shares workload, improves quality, attracts more contributors into the project.
How do you demonstrate that you respect your distribution and their community?
Read the packaging docs! Ubuntu is closely based on Debian, so start with the Debian Policy Manual and the Debian Developer's Reference. Yes, they're dense reading material. You don't have to memorise the whole thing, skim it, skip to the parts you need at first, and become familiar with it.
Search the web for other packaging guides eg. this series on Debian/Ubuntu packaging with Docker. It's important that you take in the underlying philosophy: build packages from source, in a clean environment so that you (a) know for sure the package is open source and buildable from scratch! and (b) you know you have all the dependencies, requirements, etc. Another tool for this is PBuilder (see also Ubuntu's PBuilder HowTo although I think that's gone by the wayside a bit.
In particular, this comment of yours is somewhat contrary to that philosophy:
I was shipping the release tarball containing the prebuilt binaries in the deb package, and provided the source along with it
Build some simple "hello world" style packages first. One that's just a single file C program. Look at how other packages are done, especially DKMS packages. Make changes to them yourself. Use them as a starting point.
How do you respect your users?
Be one. It sounds like you are, great! But do you use every feature? Do you test installation on all the systems you distribute for? Use VMs, even for kernel packages you can at least test that your package installs properly!
Make it clear how to get help, and who from. Users don't want an annoyed response from a developer any more than the developer wants to deal with bug reports for something that's not their problem. Make sure the Launchpad site for your PPA has the relevant features disabled if you're not going to use them. (Seriously, I have lost count of the number of times I've asked a question on Launchpad for a PPA package only to have it ignored for years.)
This might seem like a lot. But don't despair! As I said above, you don't have to do everything, but you should (a) do and commit to at least some of these things, (b) be aware of them (or, if you disagree with them, your own set).
Finally, remember your responsibility to yourself as well! You are a developer too — set your own boundaries, be realistic about what you can commit to, and watch yourself for burnout. Be kind to yourself, and if you can't work on a project in a way that makes you happy, maybe it's time to move on.