SQL Server 2012 :: Implicit Conversion Comparing INT Column To 0?

In a stored procedure, the following code is causing a huge read and CPU load when it really shouldn't. The @IDParameter below is coming in as a parameter to the proc.

Here's the snippet of code where the problem is coming in:

DECLARE @ID INT;
SET @ID = (SELECT ID From OtherTable WHERE FKID = @IDParameter);
SELECT COUNT(*)
FROM LargeTable

WHERE MostlyZeroID = @ID AND MostlyZeroID > 0Most (90+%) of the MostlyZeroID rows are 0 (hence the name) but regardless of distribution this should evaluate with minimal work on SQL Server's part to 0. However, when this was run, it is using a ton of CPU and doing a ton of Reads as it seeks through the entire index. When I look at the execution plan, I see under the seek predicate a Scalar Operator(CONVERT_IMPLICIT(int,[@1],0)) which is what is destroying the performance.

I've confirmed that the MostlyZeroID column in the LargeTable is defined as an INT NOT NULL. I also tested the scenario outside the stored procedure without any variables as the following to make sure it wasn't some kind of strange parameter sniffing scenario:

SELECT COUNT(*)
FROM LargeTable
WHERE MostlyZeroID = 0 AND MostlyZeroID > 0

However, this query also did the implicit conversion. I then tried this out on a temp table populated with a similar number of records (100 million) with a similar distribution and I didn't get the implicit conversion (I got a constant scan as I would've expected) when I did this:

SELECT COUNT(*)
FROM #TestTable
WHERE MostlyZero = 0 AND MostlyZero > 0

I also tried the same on several other tables that are set up similarly (large amount of zeros in an INT column) and I always got a constant scan and didn't do an implicit conversion.

why the query engine is interpreting this 0 as something other than an INT and doing an implicit conversion when getting the count in the scenario above? What can be done to protect against it? In the above scenario, an IF @ID > 0 statement was placed before the code including the count since there was no reason to even run the code if the @ID was equal to zero.