Removing the filter rule doesn't actually fix anything and in fact removes a level of validation (there's no longer an assurance that the value is a valid URL). The correct fix would be to adjust the URL validation to allow these types of relative URLs and not just require absolute URLs.

Ok. I dont suppose thats the right way
But this is temporal decision cause i need site to be available both on http and https.
Its very important for SEO (Yandex) in process of site migration to https

If you have a piece of content that is available via HTTPS you can always link to it through the HTTPS link, it doesn't need to be protocol relative. The one thing that will be an issue for you is if your page is loaded over HTTPS and tries to use HTTP, most browsers will raise a warning or block that secure-to-insecure request.

Yep, and thats important issue.
Also link from http://site.com to https://site.com/banner-page will be external link too. Bad for SEO too (I mean Yandex, Google is pretty much easier)

Your site should never be available on both http and https - thats really bad for SEO. So i dont see what the problem is to be fixed here

Ignoring the HTTP versus HTTPS issue, it seems like our URL filters and/or validation disallow relative URLs.

So that is a different and more generic issue. I dont see how a relative url could be validated though as it wont look any different to plain text. URL without a protocol eg beginning // should be made to validate though

We could add relative=true to the xml and that would allow relative urls to be saved
We would then need to change the banners click code to support it ie add the domain at the front because the banner system is designed to "mask" the url and it simply redirects to the value stored in the clickurl field
None of that will really help you as you do not want the banner to open in a new window etc

At the end of the day the banners component is designed for banners linking to other sites and not your own