I can reproduce this behavior using the GraphHopper and Valhalla routing engines but not OSRM, which suggests that it might be suboptimal behavior in the routing engine rather than something inherent in the data. My guess is that GraphHopper and Valhalla care too much about the fact that Cleveland Street has a higher speed limit and aren’t penalizing the backtracking by enough. OSRM’s debug map shows some slight penalties along Cleveland Street, probably due to the road’s slight curvature.
destination:street=* is by no means limited to highway exits. However, it along with destination=* are intended for green destination signs – if not the big highway signs, then at least the smaller ones at intersections that have arrows on them. I don’t see any in Bing Streetside imagery at a glance, but maybe I missed them or they’re newer than the imagery. In any case, since these are two-way streets, you’d have to qualify the tag as destination:street:forward=* or destination:street:backward=*, depending on the way’s direction, to avoid telling people going the other way about 152nd Avenue.
(See this lengthy post for more about destination:street=* and why you might consider destination=* instead on highway exits.)
We generally avoid optimizing for a specific data consumer in favor of hewing to the truth on the ground. The website only integrates these three routers as a QA tool to catch actual errors in the data, but workarounds are frowned upon. The first step would be to double-check that all the speed limits in the area correctly reflect the speed limits currently in effect. Beyond that, which GPS unit or application are you using? Maybe there’s an opportunity to get the developers to adjust their weighting?