If you have any injection sites within the following locations, the restrictions mentioned are not enough to prevent XSS:
- Within an HTML element tag, e.g. as an HTML attribute value. You can end one attribute and start a new one, including event handlers and so on.
- Within a script block. No need to provide the closing (or opening!) script tags if you're already between valid ones.
Additionally, if you check the client-side script, you might find opportunities for DOM-based XSS (where client script takes some user-controlled input and treats it as code, either by injecting it directly into the DOM without suitable escaping, or executing it as code e.g. via JS
However, the mitigation you've described (why do you think the site "does not have XSS in their scope", given that they've implemented this obviously-anti-XSS measure?) is sufficient to prevent adding your own complete HTML elements or breaking out of HTML comments or CDATA sections (although those are XML/XHTML and not HTML constructs and thus rarely seen in modern sites). Without that, you won't be able to get stored or reflected XSS unless you can find an injection point that isn't just in the document body (specifically, one that satisfies the above bullet points) or an injection point where this escaping isn't performed.