The first solution definitely has syntax errors. I guess the question I have do you want a calculation at the row level (declan_k) or at the grouping level (sonam).
However, there is some redundancy in the above code (solutions). Also, a "Lb" for a PO_SIZE will not calculate correctly.
Let's have some fun!
I always like to create a sample database when doing these answers.
-- Sample table
CREATE TABLE #WHSE_LINE_ITEM
(
ITEM_ID INT,
PO_NUM VARCHAR(10),
ITEM_NUM VARCHAR(10),
NET_COST REAL,
ADJ_EXT_NET_COST REAL,
LINE_QUANTITY INT,
TOTAL_WEIGHT REAL,
PO_SIZE VARCHAR(10)
);
-- Sample data
INSERT INTO #WHSE_LINE_ITEM
VALUES
(1, 'L22411301', '1730', 200.00, 0.0, 3.0, 15.0, 'LB'),
(2, 'L22411301', '1730', 150.00, 0.0, 3.0, 30.0, 'lb'),
(3, 'L22411301', '1343', 100.00, 0.0, 4.0, 0.0, 'LN');
I did a calculation at the row level. I hope this is what your were looking for.
-- Calculate field using case stmt
SELECT
CASE
WHEN (LOWER(PO_SIZE) like '%lb%') THEN
CAST((NET_COST / TOTAL_WEIGHT) AS DECIMAL (13,4))
ELSE
CAST((NET_COST / LINE_QUANTITY) AS DECIMAL (13,4))
END AS NEWCST,
*
FROM
#WHSE_LINE_ITEM
WHERE
PO_NUM = 'L22411301' AND
ITEM_NUM IN('1730','1343');
When looking at code, I always try reduce the size to a minimum. If you are testing for all combinations of pound (Lb, lB, lb, or LB), why not convert to a lower case string before the pattern match?
The resulting query results are below.

Food for thought, if you are running this query many times over the day, you might want to have a persisted computed field.
Check out the MSDN entry for 2012. This will save the engine from having to calculate the field every time at the expense of storing the results on disk.