Steps to reproduce:

1. Get a trigger in Problem state. See it listed in Monitoring -> Problems and dashboard widgets. 
2. Disable the trigger or item for it in host or template. See the trigger is not listed in the Problems page thus it is invisible for the frontend.

Result:

Using the Debug mode see that the problem event generated by the disabled trigger is still listed in the array returned by problem.get API. 

Set the trigger back to enabled and see it returns to Problem page (expected). 

Expected:
Problems are not returned by API for triggers that are not actually displayed by web interface. 

While this is not such a big deal on "normal" daily use, there can be edge cases where this makes the web interface almost unusable. One such happened during a performance test with many triggers having multiple event generation mode on. It is understandable that displaying all those problems generate load but it exhausts all the PHP memory limit even after the items were disabled.

The problem events are removed only after the items / triggers are deleted (or unlinked from hosts).