At a push; if it's stupid and it works, it ain't stupid. Sometimes, you are severely limited in your options and if this is the only option that you're able to implement and it does what you need it to do, then sure.
That being said, I'm hard-pressed to agree that this is the better route to take here.
Even though ASMX is old, I tired to do everything according to modern standards. So I have a UI layer (web service layer), business layer (service layer) and a data layer (for talking to the database).
The "modern" standard you're referring to here is one that was already well established back in the ASMX days. That's not to say that there haven't been implementations where layers were not correctly separated, but this basic layer separation is not somehow more modern than ASMX itself.
Having to "New" a service class every time is quite annoying
If your sole concern is the annoyance of having to instantiate objects; that's IMHO not a good enough to reason to make this level of good practice shortcut. You're bringing a lot of negative side effect to the table and you're not getting anything meaningful in return.
and I can see a maintainer (or myself) forgetting to do this and then getting the null reference exception
I infer from this that you are not testing your code. That is a much bigger and more important fish to fry.
By using statics, you are also irrevocably closing the door to (unit) testing, as it renders you unable to mock your service. This is a detriment that far outweighs the benefit of "not having to new a service instance".
and I don't think it's worth the trouble trying to get it to work
DI by itself isn't something you need. It doesn't directly deliver any of your software requirements.
However, DI is an approach that is fairly easy to implement and it enables/simplifies several good practice approaches that will directly impact your ability to deliver and maintain the software requirements. The avoidance of DI itself is not the biggest loss to your deliverables, but shutting the door to all those good practice approaches is a significant loss.
Summing it all up; it seems that you are working in a bad practice codebase. ASMX completely aside, it seems that there is tight coupling and no testing in your codebase, both of which are major red flags.
Your question then reads like it's asking for permission to double down (and permanently enshrine) these bad practices (or call it lack of good practices, if you prefer).
This will significantly impact the stability, maintainability and longevity of the project. I would consider these to already be compromised based on what I infer your codebase is currently like; but putting the statics on top of that makes it significantly harder to turn this ship around in the future.
Unless this project is already close to delivery and you intend for this project to reach its end of life very soon; the choice you're suggesting to make here will significantly hamper your future development efforts.
Really, really reconsider.
That being said, we cycle back to my initial point. Sometimes you're not given the freedom (time, budget) to do things the right way. It's not something a developer enjoys, but it's one of those facts of life that we can't always escape.
But if this is the case, and there is someone else who is putting up these boundaries, they need to be made aware of the consequences of those boundaries, so that they can make an informed decision, rather than a decision for ulterior (non-technical) reasons and forgetting to estimate the impact of that decision on the technical side of things.
